Mysql数据库优化

    提到mysql数据库优化，很多人都有很多想法吧，那就开始吧，我也总结一下。

    一，从存储引擎开始

     选InnoDB

     主流的存储引擎是MyISAM和InnoDB 

      InnoDB 事务型引擎 采用MVCC来支持高并发 默认级别REPEATABL READ（可重复读） ，并且通过间隙锁策略防止幻读。间隙锁使得InnoDB不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，防止幻影行的插入。而且官方一直在对其作优化。而且InnoDB具有自动回收碎片和表损坏自动恢复机制

      MyISAM 不支持事务和行级锁。MyISAM是表锁

     二，从表结构设计

     1，更小的数据结更好：

      尽量使用正确存储数据的最小数据类型，更小的数据类型通常更快，因为他们占用更少的磁盘、内存和cpu缓存。简单的数据类型的操作通常需要更少的cpu周期。例如 整形比字符操作代价更低，因为字符集和校对规则排序规则使字符比较比整型的比较更复杂。

     2，尽量的避免Null

     如果查询中包含可为Null的列，对mysql来说更难优化，因为可以null的列是的使得索引，索引统计和值更为复杂。可为NULL的列会使用更多的存储空间，在mysql里面也需特殊处理。当可为null的列被索引时，每个索引记录需要一个额外的字节。在列上建立索引时候，就应该尽量避免设计成null的列

     3，尽量避免使用BLOB和TEXT

     与其他类型不同，mysql把每个blob和text值当作一个独立的对象处理。存储引擎在存储时通常会做特殊处理。当blob和text值太大时，InnoDB会使用专门的外部存储区域来进行存储，此时每个值在行内需要1~4个字节存储一个指针，然后再外部存储区域存储实际的值。blob和text家族之间既有的不同是blob类型存储的是二进制数据，没有排序规则或字符集，而text类型有字符集和排序规则。mysql不能将blob和text列全部长度的字符串进行索引，也不能使用这些索引消除排序。

      4，一个表不要使用太多的列

      mysql的存储引擎API工作时需要在服务器曾和存储引擎曾之间通过行缓冲格式拷贝数据，然后再数据服务层将缓冲内容解码成各个列。从行缓冲中将编码过的列转换成数据结构的操作代价是非常高的。MyISAM的定长结构实际上与服务器曾的行结构正好匹配，所以不需要转换。然而，MyISAM的变长行结构和InnoDB的行结构则总是需要转换的。转换的代价依赖于列的数量。

     5，不要有太多的关联

       mysql限制每个关联操作最多只能有61张表 ，如果希望查询执行的快速且并发性好，每个查询最好在12个表以内做关联

    6，范式和反范式的设计选择

    范式化设计的schema的缺点是需要关联，稍微复杂一些的语句查询在符合范式的schema上都需要至少一次关联，也许更多。这带来代价昂贵 也可能使一些索引策略无效

     反范式话的schema因为所居都在一个表中，可以很好的避免关联。

     我们需要或用范式化和反范式化 混用。可能使用部分范式化schema、缓存表 以及其他技巧。

     三 索引啊 索引

      索引的优点总结：1）索引大大减少服务器需要扫描的数据量  2）索引可以帮助服务器避免排序和临时表   3）索引可以将随机I/O变为顺序I/O。

        评价一个索引是否适合某个查询的“三星系统” ：

        一星：索引将相关的记录放在一起。

        二星：索引的数据顺序和查找中的排序顺序一致。

        三星：索引中的列包含了查询中需要的全部列。

       索引是越多越好吗？

        多余的索引会急剧的增加内存和磁盘空间 ，增加新索引会将导致INSERT、UPDATE、DELETE等操作的速度变慢，特别当新增索引后达到内存瓶颈时候。而且过多的索引，在mysql预热的时候也需要非常长的时间

       四、其他影响

        1，向数据库请求了不需要的数据

              1）查询不需要的记录

               2）多表关联时返回全部的列

               3）总是去除全部的列

               4）重复查询相同的数据

         2,是否正扫描额外的记录

           1）响应时间

                响应时间是 服务时间和排队时间的和   服务时间是 数据库处理这个查询的真正花的时间  排队时间 指服务器i那位等待某些资源而没有真正的执行查询时间     等待时间一般是I/O和锁等待

            2）扫描行数和返回行数  

         3，一般mysql能够使用三种方式应用where条件   ，从好到坏依次是

           1）索引中是使用where条件来过滤不匹配的记录。这是在存储引擎层完成

            2）使用索引覆盖扫描 （在Extra列中出现Using index）来返回记录，直接从索引中过滤不需要的记录并返回明宏的结果。这是在Mysql服务器层完成的，但无需再回表查询数据

            3）从数据表中返回数据，然后过滤不满足条件的记录（在Extra列中出现Using Where）。这在mysql服务器层完成，mysql需要先从数据表中独处记录然后过滤

          4，大查询切分成小查询  

          5，count 和 min max的优化

           无论是怎么样 count 和min max 这三种都需要扫描整个表，这样造成很大的性能瓶颈，尽可能地避免使用count 或者min max 如果可以 用一些其他的方式来代替出现瓶颈问题的count  min 和max  这些函数 是不可能被优化器优化只能通过手动的避免或者使用。

          6，mysql配置文件修改

            mysql官方的说法是  除非有必要，不要动mysql的配置，如果动了之后 要做大量的基准测试，去评判是否配置调优了性能

            基础配置基本上两个：缓冲池（Buffer Pool） 和 日志文件（Log File） 

             一般来讲 缓冲池配置为服务器的75%~80% 但这个是偶然的，不精确的数字，和服务器运行的状态运行的程序有很大关系，需要反复测试来得到一个完美的值

 

 

还有很多优化方式 以上就这么多。

以上就这么多