表递增ID做数据迁移，查询效率问题。
0
悬赏园豆：10
[待解决问题]
数据表描述：一张生产表， 数据量在 150W条数据，但是ID 递增已经到了 3000W了，因为中间一致被人DELETE 数据，但是ID一致在递增。现在就形成了 ID 1-50000是没有的， 50000-100000是在表里面的，后面也是这种断断续续的存在和不存在，但是数据递增还是3000W往后。
问题描述：查询效率特别低下，做数据迁移，已经将150W条数据 压缩到 10W条数据，但是效率还是低下，CPU使用率特别高。多个子系统使用 SELECT * FROM TABLE 语句。
结果猜测：SELECT *FROM 这种查询默认表里面 还是 3000W+ 数据 并不是实际 10W条数据，有没有什么好的方案 对这种生产库的表 做数据迁移？
所有回答(5)
0
解决现有数据方法：把表数据全盘导出本地，移除ID列。重新insert生成一遍（要保证该ID号 没有被其他表所关联。否则这么整 就乱套了）；
解决后续新插入数据：改逻辑。弃用自增，新建列、使用自定义生成序列号。记得加索引
同 期待他人更好的方案
整个库都是这种方式，ID都是其他表的外键
0
不要select * from
建索引啥的
把这个表数据备份的其他表中，然后做个映射以保存老数据？
表分区啥的
id不要数字
我不是干数据库的，但是我见大佬这么做过
老项目 我已经没办法重新了
0
如果你的ID是主键，就算中间缺了是不会影响查询效率的，最多影响的是插入的时候，需要重建B树，有点影响，
稳定以后，根本不会对查询效率有影响
顶，主键是默认自增ID，从B+树考虑不会影响查询效率。数据压缩到了10W，数据量已经很小了。可以考虑一楼做法，导入导出重建索引。也可以考虑是否因为数据的删除和插入过多导致数据页碎片过多，采用optimize table的方式优化下。
其他优化：索引做太多，并且写操作也不少，导致二级索引来回重建也会影响读取速度。
代码层面：除了select * 是否查询过程中有用limit offset做分页。可以子查询主键再做分页等
@khal_Cgg: 长知识了
0
'不知道风往哪儿吹' post looks correct. You may need to build index against to the table.
What database are you having issues?
0
重建id序列的话不需要导入导出，先把所有所有id 都减50000 ，update set id = id-50000;
然后重新设置自增起始 alert 表明 set auto_increment=1
