加索引查询仍慢主因是查询未命中索引结构，如使用!=、函数、like ‘%abc’、违反最左前缀原则等；需用explain验证，合理设计复合索引顺序与覆盖索引，并定期清理无用索引。
为什么加了索引查询还是慢
索引不是万能的，加了 CREATE INDEX 却没效果，大概率是查询条件没命中索引结构。比如对 status 字段建了单列索引，但查询写成 WHERE status != 'done'，mysql 通常不会走索引；又或者用了函数包裹字段：WHERE YEAR(created_at) = 2023，直接让索引失效。
实操建议：
- 用
EXPLAIN看type是否为range或ref，key列是否显示你建的索引名 - 避免在
WHERE子句里对索引列做运算、类型转换或使用LIKE '%abc' - 联合索引要注意最左前缀：给
(user_id, status, created_at)建索引，WHERE status = 'pending'不会走索引，但WHERE user_id = 123 AND status = 'pending'可以
复合索引字段顺序怎么排
字段顺序决定索引能否复用。不是按“常用程度”排，而是按“过滤强度 + 查询模式”定。高区分度字段（如 user_id）放前面，能快速缩小数据集；低区分度字段（如 is_deleted，只有 0/1）放后面，否则前导字段一塌糊涂，整个索引基本废掉。
实操建议：
- 优先把
=条件的列放最左，再放IN，最后放范围查询（>、BETWEEN）——因为范围之后的字段无法用于索引查找 - 如果常查
WHERE tenant_id = ? AND created_at > ?，索引应为(tenant_id, created_at)，反过来就只用上第一个字段 - 覆盖索引场景下，把
select中要取的字段也加到索引末尾，避免回表，比如INDEX (user_id, status, updated_at)配合SELECT status, updated_at FROM t WHERE user_id = 123
什么时候该删索引而不是加索引
每多一个索引，写操作（INSERT/UPDATE/DELETE）就要多维护一份 B+ 树，还吃内存和磁盘空间。线上表如果有 10+ 个索引，但 information_schema.STATISTICS 显示其中几个 SEQ_IN_INDEX = 1 的字段从没出现在任何 WHERE 或 JOIN 条件里，就是纯负担。
实操建议：
- 查
sys.schema_unused_indexes（MySQL 8.0+）或用performance_schema.table_io_waits_summary_by_index_usage找长期未被使用的索引 - 删除前先用
ALTER TABLE ... DROP INDEX，别直接DROP INDEX忘记加表名，容易误操作 - 注意外键约束隐式创建的索引不能删，否则
ALTER TABLE会报错Error 1553 (HY000)
大字段（TEXT/BLOB）和索引冲突怎么解
MySQL 对索引长度有限制：InnoDB 单列索引最多 767 字节（utf8mb4 下约 191 个字符），超长字段直接建索引会报 ERROR 1071 (42000)。硬截断（title(100)）可能让索引失去业务意义；全量索引又不现实。
实操建议：
- 优先考虑生成摘要字段：比如对
content TEXT建触发器，存SUBSTR(SHA2(content, 256), 1, 32)到content_hash char(32)，再对这个字段建索引 - 全文索引（
FULLTEXT）适合搜索类场景，但只支持MyISAM和InnoDB（5.6+），且不支持模糊前缀匹配 - 不要对
json字段整体建索引，要用虚拟列提取路径值再索引，例如ALTER TABLE t ADD content_type VARCHAR(20) AS (json_unquote(json_extract(data, '$.type')))，然后索引content_type
真正卡住性能的，往往不是没建索引，而是索引建在了错误的抽象层上——比如用字符串枚举值当查询主干，却不加对应数值化映射；或者把时间范围查询压在 DATETIME 上，却忘了分区表或时间分片才是更彻底的解法。这些不在索引本身，但在表设计里埋得更深。