有效，但仅限于结构层面；alter database...collate不重建表或索引，只修改库级默认值，字段及索引的排序规则保持不变。
ALTER DATABASE 修改 COLLATE 后，现有索引还有效吗？
有效，但仅限于「结构层面」——ALTER DATABASE ... COLLATE 不重建表、不重写索引数据，只是改了库级默认值。真正影响索引行为的是字段自身的 COLLATION，不是库的默认值。
- 如果字段定义时没显式指定
COLLATE（比如建表时只写VARCHAR(255)），那它继承库默认排序规则；改库 COLLATE 后，新创建的字段会用新规则，但已有字段不变 - 已有字段的
COLLATION保持原样，对应索引的比较逻辑、排序顺序、大小写敏感性全都不变 - 想让某个字段“生效”新排序规则？必须显式执行
ALTER TABLE ... MODIFY COLUMN ... COLLATE utf8mb4_0900_as_cs（或类似），否则索引照旧工作
WHERE 条件查不出数据，是不是因为 COLLATE 不一致？
极有可能。MySQL 在字符串比较时，若左右操作数 COLLATION 不同，会隐式转换——但转换方向取决于 coercibility 值，容易导致索引失效或结果错乱。
- 典型现象：
SELECT * FROM users WHERE name = 'Alice'突然返回空，而name字段是utf8mb4_unicode_ci，但查询里字符串字面量被当成了utf8mb4_0900_as_cs - 验证方法：用
SELECT COLLATION('Alice'), COLLATION(users.name) FROM users LIMIT 1对比两边排序规则 - 临时修复：在条件中强制指定，如
WHERE name = 'Alice' COLLATE utf8mb4_unicode_ci；长期方案是统一字段和连接字符集，避免隐式转换
修改表字段 COLLATE 会锁表吗？
取决于 MySQL 版本和存储引擎。5.7+ 的 InnoDB 在多数情况下支持 ALGORITHM=INPLACE，但并非所有 COLLATE 变更都免锁。
-
utf8mb4_unicode_ci→utf8mb4_0900_as_cs这类跨系列变更，通常触发COPY算法，全程锁表（尤其大表慎用） - 同系列内变更（如
utf8mb4_0900_ai_ci→utf8mb4_0900_as_cs）可能支持原地修改，但需确认information_schema.INNODB_TRX中无长事务阻塞 - 务必在低峰期执行，并提前用
ALTER TABLE ... ALGORITHM=INPLACE, LOCK=SHARED测试是否被拒绝——被拒就说明必须走 COPY
客户端连接的 character_set_client 和 collation_connection 影响查询一致性
它们决定 SQL 字符串字面量、参数绑定的默认排序规则，和字段 COLLATE 不匹配时，就是“查得到但对不上”的根源。
- 常见错误配置：
SET NAMES utf8mb4只设了字符集，没设排序规则，此时collation_connection可能是utf8mb4_general_ci（旧版默认），而字段是utf8mb4_0900_as_cs - 验证当前会话：运行
SHOW VARIABLES LIKE 'character\_set\_client'和SHOW VARIABLES LIKE 'collation\_connection' - 安全做法：连接时显式指定，例如 PHP PDO 中加
;charset=utf8mb4;collation=utf8mb4_0900_as_cs，或执行SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs
最易被忽略的点：字段 COLLATION 是独立属性，和数据库、连接、甚至表的默认值都没强绑定。改一个地方不等于全链路同步，得逐层检查 SHOW CREATE TABLE、SHOW VARIABLES、SELECT COLLATION(...) 三处输出才能闭环。
