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

张开发
• 2026/4/19 21:48:22 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

mysql数据量过亿时索引如何优化_mysql分库分表索引设计
不是。单表过亿后加索引未必有效因B树深度增加、页分裂频繁、缓冲池命中率低且高频更新列建索引会加剧IO压力需结合执行计划、数据分布、分片策略等综合优化。单表过亿后 WHERE 查询变慢是不是加个索引就行不是。单表超亿行时INDEX 本身可能成为瓶颈B 树深度增加、页分裂频繁、缓冲池命中率暴跌。更关键的是很多“理所当然”的索引在大数据量下反而拖累写入和维护成本。实操建议先用 EXPLAIN FORMATTREE 看执行计划确认是否真走索引——有时优化器会因统计信息过期而放弃索引直接全表扫描避免在高频更新列如 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 100ALTER TABLE ... ADD INDEX 在大表上卡住不动怎么办MySQL 5.6 虽支持在线 DDL但加索引仍需拷贝表数据ALGORITHMINPLACE 仅适用于某些场景亿级表可能锁数小时且临时空间吃满磁盘。 MacsMind 电商AI超级智能客服

更多文章