问题描述，对数据库优化不太懂，我就试着重建索引，收缩了下数据库，结果如下：
开始：16308.43 MB
重建索引后：18094.56 MB
收缩后：12962.05 MB
但是目前通过SQL自带的报表分析，发现索引比数据还要大，如图：
另外表的使用情况查看，有的索引都超过2G了，感觉怪怪的，如图：
请问：我该如何优化好些，谢谢！
另外其中有一两张表数据都过千万了，好大不知道咋办了
请问：很多代码都用了这几个大表，所谓的分库，分表和我这有关系吗？请解释下，谢谢！
还有就是有个别查询一执行cpu就飚上去了，严重影响了其他客户的查询使用
请问：除了慢慢优化sql，我如何后台随时停止高cpu的查询，谢谢！
------解决思路----------------------
聚集索引你可以看成 数据+指针
------解决思路----------------------
优化索引、改写sql、修改配置
------解决思路----------------------
没有业务，只能原则性地建议一下。
千万级的数据不可能每一条都会查看明细记录的，通常会用到的是一些统计信息。
以某个时点划分，新数据（常用）保留，旧数据做成各种统计表，清除。
象 EventLog 表，超过过了某些时点应该无效了，清除之。
那个命名后缀为 _copy 的表，不是垃圾表吗？
数据库的数据不能一直累积的，定时的清除是必要的。
真要舍不得历史数据，转移到其他服务器上，查历史只能慢、只要日常操作不慢，还是比较容易接受的。
------解决思路----------------------
数据爆了加硬件，这是跑不掉的。
原始的旧数据移到另外的服务器，各种“变态统计”总比原始数据小吧，统计结果存在当前库中。
------解决思路----------------------
先找出瓶颈在哪里
------解决思路----------------------
重建后，数据库变大，是因为重建索引产生了日志
慢需要优化，比如补索引或删除多的索引，在没法调整SQL代码的情况下
也可能重新设计IO分离能提升一些性能
------解决思路----------------------
索引太多的问题.
--> 可能是索引碎片太多导致的,需定期重建(或重整)索引.
个别查询一执行cpu就飚上去的问题.
--> 通常是SQL写法不当或查询找不到合适的索引,即缺少索引.
需具体问题具体分析,用SQL Profiler工具跟踪出CPU Time较高的SQL(如大于5000ms的).
然后优化SQL写法,缺索引的话则建一下.
------解决思路----------------------
估计也就个别查询缺少索引，一般需要修改SQL+新建或者修改索引能解决
内存上去的问题可以修改数据库服务器的内存上限来解决，如果服务器没有安装其他服务，可考虑设置数据库内存上限为14G左右
索引占用大于数据是正常现象，重建索引变大、收缩变小也正常
可考虑定时转走历史数据以保持在线数据库表不太大