SQL强化阶段主要是对索引的投弹情况展开分析，而他们也知道SQL强化并并非LX1的，在绝对的统计信息量情况下，SQL再怎么强化也即便难逃慢的故事情节。因此他们就须要从内部结构设计微观去提供许多强化的路子，这里他们主要会介绍许多在索引、表内部结构上的内部结构设计强化，那些强化方式会具有许多情景性并并非LX1的，但那些事例的路子是大家能学习的。
一、索引内部结构设计
索引的必要性是显而易见的，他们不但要在查阅的这时候展开索引的调整，而是在内部结构设计阶段就要根据索引的特性来内部结构设计最合适的索引，不最合适的索引不但不行反而有可能影响他们的SQL工作效率，在内部结构设计索引的这时候他们要遵从许多原则，这会帮助他们能内部结构设计出高效率的索引。
1.1、常用表头创建索引
时常要用作查阅的列 where id=?。
时常要用作次序(order by)，各组(group by)的列，即使索引已经排好序了。
极线同一性限制的列，比如说换行符、帐号。
1.2、大表头不适宜创建索引
大表头上创建索引会直接引致他们的索引树显得巨大，即使索引树的结点大小是固定的，当表头越大因此每个索引树结点Sitapur多，引致树层次变多，树的层次越多查阅的工作效率就会越来越快。而且资料库预设会把索引读取到缓存里，大表头创建的索引Sitapur得巨大，因此也会消耗更多的物理地址。
1.3、圣马尔瑟兰县相对较低的表头不适宜创建索引
圣马尔瑟兰县相对较低是指统计数据的发展性相对较低，比如异性恋，只有男和女，因此此种表头上创建索引就算投弹了，因此每天扫描器的这时候还是须要扫描器一半的数据，因此此种表头上创建索引并不能提升索引工作效率。
1.4、更新频密的表头不适宜建索引
索引本质也是资料库附加保护的两个统计计算机程序，当他们的索引表头频密更改，那势必会也引致索引的内部结构频密更改，频密的统计数据保护和索引的更改保护会引致资料库性能的耗损。
1.5、在最合适的情景，多采用女团索引
在最合适的业务情景下，他们能多采用女团索引，Mysql的每天查阅只会采用两个索引作为索引统计数据的依据，如果要让索引采用的更有工作效率，那么他们能尽量的让索引相匹配出的统计数据越多越好，也就是让他们的索引发展性更高，女团索引就能帮他们达到这一效果，比如他们须要寻找两个人，因此采用联系电话+地区+年龄 找到统计数据显然是要比只采用联系电话去搜寻出的统计数据TGP50得多，而女团索引的功效就在于此，当然内部结构设计女团索引的这时候不要忘了遵守“最左相匹配原则”。
1.6、选择最合适的表头长度
表头的大小会影响到几方面的东西，一是表头大会使表变大，二是表头大会使索引树变大并且层次变高，三是索引变大后又会消耗掉更大的缓存。
二、表内部结构设计强化
有这时候资料库性能是无法单方面通过强化索引来达到性能的显著提升的，表统计信息量太大，联表查阅统计数据太多都是索引解决不了的问题，这个这时候他们就须要考虑到从业务微观对表内部结构展开许多内部结构设计和调整，反而是解决问题的关键。
2.1、表头冗余
表头冗余主要是减少他们的联表查阅的操作，即使展开join 查阅的这时候，他们须要相匹配的统计信息量是呈笛卡尔积的上升的，因此减少联表的操作有这时候对工作效率有显著的提升。
情景： 用户信息的关联查阅
表头冗余的两个前提条件就是这个表头的值基本不Sitapur，比如说：身份证、联系电话、还有许多系统常量的配置分类等，那些表头基本上不会改变的，而那些信息往往在他们查阅业务统计数据的这时候同时也要查阅出，这个这时候就不可避免的要展开join 用户表或系统表展开查阅，通常像用户表此种统计信息量都比较大，因此join操作会成为资料库性能的瓶颈。
此种这时候他们就能采用字段冗余的方案，在须要查阅的业务表里也冗余两个身份证、联系电话这样的表头，在插入统计数据的这时候就把对应的统计数据存入到对应的业务表中，因此查阅的这时候就不须要去展开表关联查阅了。
2.2、表冗余
表冗余一般适宜统计类的场景，比如说运营须要分析日报、周报、季报、年报等维度的统计数据，因此这个这时候他们通常能采用表冗余的路子。
情景：用户活跃度统计分析
拿用户登录统计数据分析来说，运营须要对用户最近登录的统计数据分析平台用户的活跃度，维度有日、周、月、季、年的统计统计数据。 即使系统每天登录的用户可能会有几万至几百万的统计数据，因此一周、一月的统计数据很有可能就达到了几千万的统计数据，如果z此种情况他们还是通过SQL去统计那些统计数据，因此很显然是一件非常糟糕的事情。
这个这时候就能考虑表冗余的方式了，他们能把统计数据以天为维度冗余一张统计表出，这个表里面就保存平台每天登录的统计人数记录，然后用两个定时任务每天24点执行统计一次，把统计信息插入到此表，这样的话这个表的记录每天只会增加一条，运营须要统计统计数据的这时候他们能直接查阅这张冗余表来得到统计数据，此种方式一年也就365条统计数据，工作效率将会是两个巨大的提升。
2.3、统计数据冷热分离
表统计数据的冷热分离路子就是根据业务情景来区分哪些统计数据是时常要用到的统计数据(热统计数据)，哪些统计数据基本上不用到或者很少用到（冷统计数据），如果表统计数据具备这样的业务特性，因此他们能采用统计数据冷热分离的方式对资料库展开强化。
情景：订单统计数据冷热分离。
平台订单每天上万，随着时间推移统计数据越来越多了，到了几百上千万的这时候采用索引工作效率也非常慢了，而用户查阅订单列表的功能也是两个常用且刚需的功能，这个这时候他们就采用统计数据冷热分离的路子展开强化了。
首先分析业务情景，一般情况下用户只会查阅最近一段时间下的订单，这个时间有可能就是你的一次订单周期，7天到两个月不等。 而用户基本很少去查阅两个月之前的订单统计数据，因此这个这时候他们就能根据业务情景了解到统计数据的特性了，他们此时就能通过创建一张订单的备份表，然后把订单主表两个月之前的统计数据都存放到这个备份表里去，每天定时的把超过两个月时间的订单统计数据迁移到备份表，而订单主表只保存最近两个月的订单统计数据，因此就算订单量每天上万，两个月下来订单主表也只会有三十几万统计数据，这样用户查阅订单列表的这时候性能就会得到巨大的提升。
当然用户也有查阅两个月之前统计数据的需求，这个这时候就须要查阅备份表了这个这时候可能还是比较慢，但是考虑到用户采用这样的操作频率非常低，因此也还是能接受的，当然你也能对备份表展开许多强化，比如多备份几个维度的统计数据表，两个月、两个季度，一年的，根据用户自定义的时间去查阅对应的表。
