In my testing, it looks like SHOW FULL COLUMNS
will always put the collation of the table into the results if one is not set on the column. Only for text-type columns. Numerics, dates, etc., do not have a collation.
The example table has 1 column with a collation.
CREATE TABLE `testCollationChanging` (
`apiUserID` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(128) NOT NULL,
`email` varchar(128) COLLATE latin1_general_ci NULL,
`apiKey` char(32) NOT NULL,
`companyID` int(11) NOT NULL,
`userID` int(11) NOT NULL,
PRIMARY KEY (`apiUserID`),
UNIQUE KEY `Duplicate name/company combo check` (`name`,`companyID`) USING BTREE,
UNIQUE KEY `apiKey` (`apiKey`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;
SHOW FULL COLUMNS FROM `testCollationChanging`;
ALTER TABLE `testCollationChanging` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
SHOW FULL COLUMNS FROM `testCollationChanging`;
DROP TABLE `testCollationChanging`;
This shows the following 2 result sets ...
apiUserID int(11) NO PRI auto_increment select,insert,update,references
name varchar(128) latin1_swedish_ci NO MUL select,insert,update,references
email varchar(128) latin1_general_ci YES select,insert,update,references
apiKey char(32) latin1_swedish_ci NO UNI select,insert,update,references
companyID int(11) NO select,insert,update,references
userID int(11) NO select,insert,update,references
and
apiUserID int(11) NO PRI auto_increment select,insert,update,references
name varchar(128) utf8mb4_unicode_520_ci NO MUL select,insert,update,references
email varchar(128) utf8mb4_unicode_520_ci YES select,insert,update,references
apiKey char(32) utf8mb4_unicode_520_ci NO UNI select,insert,update,references
companyID int(11) NO select,insert,update,references
userID int(11) NO select,insert,update,references
I think if the columns have inconsistent collations, you need to convert them also. In the above example, they seem to be converted appropriately.
Incorporating ...
SELECT * FROM information_schema.TABLES WHERE TABLE_NAME = 'testCollationChanging';
SELECT * FROM information_schema.COLUMNS WHERE TABLE_NAME = 'testCollationChanging';
into the results shows that the information schema is holding the collation against each column.