SQL 索引太大的优化问题

jxllove 2014-07-11 04:29:26

问题描述，对数据库优化不太懂，我就试着重建索引，收缩了下数据库，结果如下：
开始：16308.43 MB
重建索引后：18094.56 MB
收缩后：12962.05 MB
但是目前通过SQL自带的报表分析，发现索引比数据还要大，如图：

另外表的使用情况查看，有的索引都超过2G了，感觉怪怪的，如图：

请问：我该如何优化好些，谢谢！

另外其中有一两张表数据都过千万了，好大不知道咋办了
请问：很多代码都用了这几个大表，所谓的分库，分表和我这有关系吗？请解释下，谢谢！

还有就是有个别查询一执行cpu就飚上去了，严重影响了其他客户的查询使用
请问：除了慢慢优化sql，我如何后台随时停止高cpu的查询，谢谢！

...全文

1462 10 打赏收藏转发到动态举报

写回复

用AI写文章

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

昵称被占用了 2014-07-12

打赏
举报

估计也就个别查询缺少索引，一般需要修改SQL+新建或者修改索引能解决内存上去的问题可以修改数据库服务器的内存上限来解决，如果服务器没有安装其他服务，可考虑设置数据库内存上限为14G左右索引占用大于数据是正常现象，重建索引变大、收缩变小也正常可考虑定时转走历史数据以保持在线数据库表不太大

Q315054403 2014-07-12

打赏
举报

重建后，数据库变大，是因为重建索引产生了日志慢需要优化，比如补索引或删除多的索引，在没法调整SQL代码的情况下也可能重新设计IO分离能提升一些性能

唐诗三百首 2014-07-12

打赏
举报

索引太多的问题. --> 可能是索引碎片太多导致的,需定期重建(或重整)索引. 个别查询一执行cpu就飚上去的问题. --> 通常是SQL写法不当或查询找不到合适的索引,即缺少索引. 需具体问题具体分析,用SQL Profiler工具跟踪出CPU Time较高的SQL(如大于5000ms的). 然后优化SQL写法,缺索引的话则建一下.

發糞塗牆 2014-07-11

打赏
举报

先找出瓶颈在哪里

Tiger_Zhao 2014-07-11

打赏
举报

数据爆了加硬件，这是跑不掉的。
原始的旧数据移到另外的服务器，各种“变态统计”总比原始数据小吧，统计结果存在当前库中。

jxllove 2014-07-11

打赏
举报

引用 4 楼 Tiger_Zhao 的回复:

没有业务，只能原则性地建议一下。千万级的数据不可能每一条都会查看明细记录的，通常会用到的是一些统计信息。以某个时点划分，新数据（常用）保留，旧数据做成各种统计表，清除。象 EventLog 表，超过过了某些时点应该无效了，清除之。那个命名后缀为 _copy 的表，不是垃圾表吗？数据库的数据不能一直累积的，定时的清除是必要的。真要舍不得历史数据，转移到其他服务器上，查历史只能慢、只要日常操作不慢，还是比较容易接受的。

这个详情肯定是需要的，查询某次的记录然后点进去就要看到明细另外日志也是需要的，为这个我前几天我还专门做了个登陆次数统计的报表客户很变态，各种统计表都能想出来，另外只有一台服务器，16G内存的，平时内存占用都是15G，重启了很快就飚上去，10天一重启， sql的最大内存设置我设置的12G貌似不管用，还望指教下，谢谢

Tiger_Zhao 2014-07-11

打赏
举报

没有业务，只能原则性地建议一下。

千万级的数据不可能每一条都会查看明细记录的，通常会用到的是一些统计信息。
以某个时点划分，新数据（常用）保留，旧数据做成各种统计表，清除。

象 EventLog 表，超过过了某些时点应该无效了，清除之。

那个命名后缀为 _copy 的表，不是垃圾表吗？

数据库的数据不能一直累积的，定时的清除是必要的。
真要舍不得历史数据，转移到其他服务器上，查历史只能慢、只要日常操作不慢，还是比较容易接受的。

發糞塗牆 2014-07-11