为什么你的接口响应慢？数据库索引设计九个反例

接口响应慢往往是数据库拖了后腿。而在数据库性能问题中索引设计不当又是最常见的元凶。很多开发者知道“要加索引”却不知道“怎么加才对”。以下九个反例值得逐一对照自查。反例一该加索引的列没加全表扫描成常态最常见的低级错误。WHERE 条件、JOIN 关联列、ORDER BY 排序列上缺少索引数据库只能逐行扫描。一张百万级表全表扫描轻松吃掉几百毫秒甚至数秒。排查方法很简单开启慢查询日志看执行计划里是否出现type: ALL。反例二在索引列上使用函数或表达式sql复制下载SELECT FROM orders WHERE DATE(create_time) 2024-01-01;对索引列施加函数后B树无法直接定位索引直接失效。正确写法是改为范围查询sql复制下载WHERE create_time 2024-01-01 AND create_time 2024-01-02反例三隐式类型转换user_id是 VARCHAR 类型查询却写成WHERE user_id 12345。MySQL 会将字符串列隐式转为数字比较等价于对索引列施加了函数索引失效。类型必须严格对齐。反例四前导通配符 LIKE 查询sql复制下载WHERE name LIKE %张三%B树按前缀有序排列左模糊无法利用有序性只能全表扫描。若业务确实需要模糊搜索应考虑全文索引或搜索引擎而非在 B树上硬扛。反例五复合索引顺序错误违背最左前缀原则建立复合索引(a, b, c)查询条件却是WHERE b ? AND c ?索引无法被有效利用。复合索引的列顺序应按“等值条件在前、范围条件在后、高区分度在前”来排列并确保查询能命中前缀。反例六在低区分度列上建索引性别、状态标志这类只有几个值的列索引选择性极差。走索引反而可能比全表扫描更慢因为回表次数太多。这类列适合放在复合索引的末尾而非单独建索引。反例七索引过多写入性能被拖垮每个索引都是一棵额外的 B树。INSERT、UPDATE、DELETE 都要同步维护所有索引。一张表建了十几个索引写入放大严重接口的写操作自然变慢。索引不是越多越好够用即可定期清理无用索引。反例八使用 OR 连接不同列sql复制下载WHERE a 1 OR b 2若 a 和 b 各自有独立索引MySQL 可能选择全表扫描而非索引合并。可改写为UNION ALL分别走索引或建立覆盖两列的复合索引。反例九忽略覆盖索引频繁回表查询需要的列不在索引中即使命中索引也要回表取数据。若将 SELECT 的列全部纳入索引覆盖索引数据库可直接从索引返回结果省去回表开销。对于高频核心查询覆盖索引往往能带来数倍提升。结语索引设计的核心是让数据库用最少的页读取定位到数据。每一个反例背后都是对 B树工作原理的违背。养成看执行计划的习惯用EXPLAIN验证每一步查询才能让接口真正快起来。