某电商公司双十一期间因数据库索引设计失误，导致订单查询接口响应延迟从50毫秒飙升至12秒，直接损失近千万交易额。事后复盘发现，团队在数据库管理中反复踩中的3个坑，正是同行咨询最多的共性问题。

索引选择性：为什么加了索引反而更慢？

想象一个记录用户性别的字段，99%都是“男”且只有1%“女”——在这个字段上建索引，查询“男”时数据库需要扫描近全表数据，还要额外维护索引树，性能反而不如全表扫描。更典型的场景是：某金融系统在交易流水表的“交易状态”字段（仅“成功”“失败”“处理中”3种值）上建索引，结果状态为“成功”的查询耗时增加3倍。正确做法是优先选择高选择性的字段（如订单号、身份证号），对低选择性字段考虑位图索引或直接放弃索引。

连接池大小：为何增加连接数反而拖垮数据库？

某SaaS平台将连接池从50扩到200后，数据库CPU使用率直接从60%冲到98%，TPS反而下降30%。核心原因在于：每个活动连接都会占用数据库的线程、锁和内存资源，当连接数超过CPU核心数的2-3倍时，上下文切换开销会吞噬有效计算能力。以PostgreSQL为例，推荐连接池大小 = (CPU核心数 * 2) + 少量预留连接。更有效的方式是使用连接池中间件（如PgBouncer、Druid）复用连接，而非粗暴扩容。

慢查询定位：为什么explain分析不出来？

某物流系统的查询在测试环境执行200毫秒，上线后却频繁超时。排查发现：测试表只有10万行数据，而生产表已超2000万行。explain显示的索引使用计划在数据量级差异时可能完全不同。更隐蔽的问题是隐式类型转换——用户表user_id字段为varchar类型，但查询用整数类型传参，导致索引失效。建议日常慢查询排查中，强制用真实生产数据比例的测试集，并额外监控rows_examined（扫描行数）和extra中的“Using filesort”等关键标记。

• 误区1：盲目给每个字段加索引——索引不是越多越好，写入频繁的表每增一个索引，写入性能下降约5%-10%。
• 误区2：连接池参数照搬默认配置——大多数框架默认值（如HikariCP的10个连接）对高并发场景远不够，需结合应用服务器CPU核数、数据库规格计算。
• 误区3：只关注查询时间而忽略锁等待——长期运行的未提交事务会阻塞其他查询，定期用SELECT * FROM pg_stat_activity WHERE state = 'active'（MySQL用SHOW PROCESSLIST）揪出“僵尸事务”是关键。