以为索引越多越好
很多开发人员一碰到查询慢，第一反应就是加索引。于是表里一个字段一个索引，主键有索引，外键加索引，连性别这种只有“男”“女”的字段也建了索引。实际效果呢？写入变慢，存储占用上升，查询却没快多少。
比如用户表的“性别”字段，如果90%的数据都是“男”，数据库优化器大概率不会走这个索引，因为全表扫描反而更快。索引不是贴金，建一个就灵，它只对区分度高的字段真正有用。
忽略了复合索引的顺序
复合索引讲究“最左前缀原则”。比如你建了个索引 (a, b, c)，只有当你查询条件从 a 开始，才能有效利用这个索引。如果只查 b 和 c，那这个索引基本废了。
举个例子：有张订单表，按 (user_id, status, create_time) 建了索引。你想查“所有已支付的订单”，只用了 status 字段，结果发现索引没生效。原因就在这儿——没走最左边的 user_id。
在函数中使用索引字段
有时候为了方便，会这样写SQL：
SELECT * FROM users WHERE YEAR(create_time) = 2023正确做法是把条件改写成范围查询：
SELECT * FROM users WHERE create_time >= '2023-01-01' AND create_time < '2024-01-01'盲目相信唯一索引能提升性能
唯一索引确实能防止重复数据，但它的主要作用是约束，不是提速。在某些高并发写入场景下，唯一索引还会成为性能瓶颈，因为每次插入都要检查冲突。
比如注册系统，你在 email 字段加了唯一索引，本意是防重。但如果大量请求同时注册，数据库就得串行化检查，响应时间蹭蹭往上涨。这时候可能得靠应用层缓存或分布式锁来缓解。
忽视了索引维护成本
索引不是建完就一劳永逸。每当你插入、更新、删除数据，数据库都得同步更新对应的索引树。表越大，索引越多，这个代价越明显。
有个朋友的运营后台，每天跑报表时卡得不行。一看表结构，8个索引，而实际查询只用了两个。删掉冗余索引后，写入速度回升，查询也没受影响。
误判执行计划
看到 SQL 执行慢，直接加索引，但从不看执行计划（EXPLAIN）。结果可能是索引建了一堆，实际执行还是走全表扫描。
比如 join 查询，驱动表选错了，或者关联字段字符集不一致，索引照样失效。这时候该查的是表设计和 SQL 写法，而不是拼命加索引。
用好索引，关键在理解数据分布和查询模式。别把它当万能药，更别当成逃避优化的借口。