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