mysql数据量过亿时索引如何优化_mysql分库分表索引设计

不是。单表过亿后加索引未必有效，因B+树深度增加、页分裂频繁、缓冲池命中率低，且高频更新列建索引会加剧IO压力；需结合执行计划、数据分布、分片策略等综合优化。单表过亿后 WHERE 查询变慢，是不是加个索引就行？不是。单表超亿行时，INDEX 本身可能成为瓶颈：B+ 树深度增加、页分裂频繁、缓冲池命中率暴跌。更关键的是，很多“理所当然”的索引在大数据量下反而拖累写入和维护成本。实操建议：先用 EXPLAIN FORMAT=TREE 看执行计划，确认是否真走索引——有时优化器会因统计信息过期而放弃索引，直接全表扫描避免在高频更新列（如 status、updated_at）上建普通二级索引，每次 UPDATE 都要回写索引页，IO 压力翻倍对 LIKE '%xxx' 或 JSON_CONTAINS() 这类无法用 B+ 树高效定位的查询，别硬扛，该上 MATCH ... AGAINST（全文索引）或迁到 Elasticsearch分库分表后全局唯一 ID 上的索引为什么总失效？因为分片键（sharding key）和查询条件不一致。比如按 user_id 分库，但业务查的是 order_no，即使 order_no 有索引，也得扫所有分片。实操建议：强制要求所有高频查询必须带上分片键，否则在应用层做路由判断前就丢弃请求（用 MySQL Router 或中间件拦截）order_no 这类非分片字段，如果必须查，优先建 UNIQUE 索引 + 提前生成带分片标识的编码（如 shard_02_order_123456），让查询能精准路由跨分片 ORDER BY ... LIMIT 是重灾区：每个分片返回 TOP N，合并后再取 LIMIT，内存和网络开销剧增——改用时间范围 + 游标分页（WHERE created_at > ? ORDER BY created_at LIMIT 100）ALTER TABLE ... ADD INDEX 在大表上卡住不动怎么办？MySQL 5.6+ 虽支持在线 DDL，但加索引仍需拷贝表数据（ALGORITHM=INPLACE 仅适用于某些场景），亿级表可能锁数小时，且临时空间吃满磁盘。 MacsMind 电商AI超级智能客服