SlideShare a Scribd company logo
1 of 84
MySQL 性能优化最佳实践
     About me




       简朝阳(sky000)
       Oracle ACE(Expertise: MySQL)
       技术保障部 @麦包包


       Blog:http://isky000.com
       Twitter:@sky000
       Weibo:@简朝阳


2012/4/16                    1
MySQL 性能优化最佳实践
     优化过程


                   找出瓶颈




            确认结果
                   优化     设定目标




                   实施优化




2012/4/16           2
MySQL 性能优化最佳实践
                              容量白菜价
                              2TB很普及
     找出瓶颈                     了



                       存储容量




              瓶颈


2012/4/16          3
MySQL 性能优化最佳实践
     找出瓶颈

                                       一般很难跑满
                                       万兆已经很多
                        存储容量

                   Network(IOPS/吞吐量)




              瓶颈


2012/4/16          4
MySQL 性能优化最佳实践
     找出瓶颈


                        存储容量
                                       Linux单机支持过百
                   Network(IOPS/吞吐量)   G
                                       价格较之过去已大降

                        DRAM




              瓶颈


2012/4/16          5
MySQL 性能优化最佳实践
     找出瓶颈


                        存储容量

                   Network(IOPS/吞吐量)

                                       X86
                        DRAM           Nehalem,SMP,NUMA
                                       4路 PC Server 32核
                                       >30%
                         CPU



              瓶颈


2012/4/16          6
MySQL 性能优化最佳实践
     找出瓶颈


                          存储容量

                   Network(IOPS/吞吐量)

                           DRAM

                            CPU        OLTP:iops
                                       OLAP:吞吐量
                       IO (IOPS/吞吐量)   >60% 瓶颈在 IO

              瓶颈                       SSD?




2012/4/16          7
MySQL 性能优化最佳实践
     设定目标

            极限不可
             能突破



                   设备能力

                      目标




2012/4/16                 8
MySQL 性能优化最佳实践
     设定目标

                                     一切以需
            极限不可                     求为导向
             能突破



                   设备能力       业务需求

                      目标




2012/4/16                 9
MySQL 性能优化最佳实践
     设定目标

                                        一切以需
            极限不可                        求为导向
             能突破



                   设备能力          业务需求

                      目标

                      应用环境




                          环境影响
                          可行性


2012/4/16                  10
MySQL 性能优化最佳实践
     实施优化


                 对象


               Hardware

                 OS

               Params

                Engine
       MySQL




               Schema

                Index

                 SQL
                          实施
2012/4/16                 11
MySQL 性能优化最佳实践
     实施优化


                 对象       方法


               Hardware

                 OS

               Params     方
                Engine
                          法
                          …
       MySQL




               Schema

                Index

                 SQL
                               实施
2012/4/16                      12
MySQL 性能优化最佳实践
     实施优化


                 对象       方法        误区


               Hardware

                 OS

               Params     方         误
                Engine
                          法         区
                          …


                                    …
       MySQL




               Schema

                Index

                 SQL
                               实施
2012/4/16                      13
MySQL 性能优化最佳实践
     实施优化


                 对象       方法        误区   最佳实践


               Hardware

                 OS

               Params     方         误     经
                Engine
                          法         区     验
                          …


                                    …


                                          …
       MySQL




               Schema

                Index

                 SQL
                               实施
2012/4/16                      14
MySQL 性能优化最佳实践
     实施优化
   转速,容量,接口
   HDD: ~150 iops, < 200MB
   SSD: 10x ~ 1000x, < 400MB

                               磁盘



                                    背景




2012/4/16                           15
MySQL 性能优化最佳实践
     实施优化
                                主频,多核,超线程
                                SMP, NUMA, MPP



                磁盘        CPU



                     背景




2012/4/16            16
MySQL 性能优化最佳实践
     实施优化



                                     ~ Balance Tree
                磁盘        CPU        缩短检索路径
                                     有序



                     背景         索引




2012/4/16            17
MySQL 性能优化最佳实践
     实施优化




                磁盘        CPU



                     背景         索引


                          SQL
                                     执行计划
                                     如何获得:explain
                                     如何分析:Docs




2012/4/16            18
MySQL 性能优化最佳实践
     实施优化




                          磁盘            CPU



                                   背景         索引



                           MySQL        SQL




            简单,轻型,开放
            多线程,插件式
            SQL+Storage Engine …


2012/4/16                          19
MySQL 性能优化最佳实践
     实施优化




                 磁盘            CPU


                存储引擎   背景            索引

   插件式,可自由更换
   开放型,可 自行开发                  SQL
   多样性,特性不一       MySQL
   并存性,可并存使用




2012/4/16                 20
MySQL 性能优化最佳实践
           方法


                        •   提高磁盘转速
                Disk    •   增加磁盘数量
                        •   选好磁盘接口
Hardware




            Raid Card




                CPU
                 …




2012/4/16                            21
MySQL 性能优化最佳实践
           误区


                        •   容量越大越好?
                Disk    •   FC磁盘一定比SAS盘快?
                        •   磁盘 Cache 越大越好?
Hardware




            Raid Card




                CPU
                 …




2012/4/16                           22
MySQL 性能优化最佳实践
       最佳实践


                        •   OLTP: 小容量”高”转速
                        •   OLAP: 大容量”低”转速(钱多可以高转
               Disk         速)
                        •   磁盘数量尽可能多
                        •   有钱可以上 SSD( IO 瓶颈场景下)
Hardware




            Raid Card




               CPU
                …




2012/4/16                           23
MySQL 性能优化最佳实践
           方法


                        •   OLTP: 小容量”高”转速
                        •   OLAP: 大容量”低”转速(钱多可以高转
                Disk        速)
                        •   磁盘数量尽可能多
                        •   有钱可以上 SSD( IO 瓶颈场景下)
Hardware




            Raid Card   •   增加Raid卡Cache容量
                        •   提升 Cache 利用率
                        •   确保数据安全




                CPU
                 …




2012/4/16                            24
MySQL 性能优化最佳实践
           误区


                        •   OLTP: 小容量”高”转速
                        •   OLAP: 大容量”低”转速(钱多可以高转
                Disk        速)
                        •   磁盘数量尽可能多
                        •   有钱可以上 SSD( IO 瓶颈场景下)
Hardware




            Raid Card   •   读写都是用 Cache 提升效率?
                        •   Raid10一定比Raid5快?
                        •   带电池的 Raid 卡数据一定安
                            全?



                CPU
                 …




2012/4/16                           25
MySQL 性能优化最佳实践
       最佳实践


                        •   OLTP: 小容量”高”转速
                        •   OLAP: 大容量”低”转速(钱多可以高转速)
               Disk     •   磁盘数量尽可能多
                        •   有钱可以上 SSD( IO 瓶颈场景下)
Hardware




                        •   Cache 只供写使用,Direct 读取
            Raid Card   •   OLTP Raid10,Strip Size 参考DB
                        •   OLAP Raid5
                        •   关注 Raid 卡充放电带来的 Cache 失效
                        •   预读只对连续读有效,OLTP 关闭预读



               CPU
                …




2012/4/16                             26
MySQL 性能优化最佳实践
           方法


                        •   OLTP: 小容量”高”转速
                        •   OLAP: 大容量”低”转速(钱多可以高转
                Disk        速)
                        •   磁盘数量尽可能多
                        •   有钱可以上 SSD( IO 瓶颈场景下)
Hardware




                        •   Cache 只供写使用,Direct 读取
            Raid Card   •   OLTP Raid10,Strip Size 参考DB
                        •   OLAP Raid5
                        •   关注 Raid 卡充放电带来的 Cache 失效
                        •   预读只对连续读有效,OLTP 关闭预读



                CPU     •   提高CPU运算能力(频率?)
                        •   缩短 CPU 访问数据的路径(缓存?)
                 …




2012/4/16                             27
MySQL 性能优化最佳实践
           误区


                        •   OLTP: 小容量”高”转速
                        •   OLAP: 大容量”低”转速(钱多可以高转
                Disk        速)
                        •   磁盘数量尽可能多
                        •   有钱可以上 SSD( IO 瓶颈场景下)
Hardware




                        •   Cache 只供写使用,Direct 读取
            Raid Card   •   OLTP Raid10,Strip Size 参考DB
                        •   OLAP Raid5
                        •   关注 Raid 卡充放电带来的 Cache 失效
                        •   预读只对连续读有效,OLTP 关闭预读



                CPU     •   CPU 越多越好?
                        •   Core 越多越好?
                 …




2012/4/16                             28
MySQL 性能优化最佳实践
       最佳实践


                        •   OLTP: 小容量”高”转速
                        •   OLAP: 大容量”低”转速(钱多可以高转
               Disk         速)
                        •   磁盘数量尽可能多
                        •   有钱可以上 SSD( IO 瓶颈场景下)
Hardware




                        •   Cache 只供写使用,Direct 读取
            Raid Card   •   OLTP Raid10,Strip Size 参考DB
                        •   OLAP Raid5
                        •   关注 Raid 卡充放电带来的 Cache 失效
                        •   预读只对连续读有效,OLTP 关闭预读

                        •   使用主频更高的 CPU
               CPU      •   使用缓存更大的 CPU
                        •   8个Core 比较合适,不超过16 Core
                        •   Core比较多可以单机多实例
                …




2012/4/16                             29
MySQL 性能优化最佳实践
      方法


                            •   确保安全:有日志,能恢复
                            •   OLTP: 提高大文件下随机I/O性能
             File System    •   OLAP: 提高大文件下连续I/O性能
                            •   降低管理成本
OS




            I/O Scheduler




            CPU/DRAM
                  …




2012/4/16                               30
MySQL 性能优化最佳实践
      误区


                            •   OS默认自带的就是最好的?
             File System    •   功能最强的才是最好的?
                            •   性能最高的才是最好的?
OS




            I/O Scheduler




            CPU/DRAM
                  …




2012/4/16                              31
MySQL 性能优化最佳实践
   最佳实践


                            •   XFS 非常适合 MySQL
             File System    •   XFS要注意su(stripe size)和sw(stripe width)
                            •   ZFS 非常适合备份管理
OS




            I/O Scheduler




            CPU/DRAM
                  …




2012/4/16                                    32
MySQL 性能优化最佳实践
      方法


                            •   XFS 非常适合 MySQL
             File System    •   XFS要注意su(stripe size)和sw(stripe width)
                            •   ZFS 非常适合备份管理
OS




            I/O Scheduler   •   尽量减少不必要阻塞
                            •   尽量降低随机I/O访问的延时
                            •   CFQ, Deadline,NOOP和Anticipatory 差异




            CPU/DRAM
                  …




2012/4/16                                    33
MySQL 性能优化最佳实践
      误区


                            •   XFS 非常适合 MySQL
             File System    •   XFS要注意su(stripe size)和sw(stripe width)
                            •   ZFS 非常适合备份管理
OS




            I/O Scheduler   •   公平的才是最合适的?
                            •   智能的就是合适的?




            CPU/DRAM
                  …




2012/4/16                                    34
MySQL 性能优化最佳实践
   最佳实践


                            •   XFS 非常适合 MySQL
             File System    •   XFS要注意su(stripe size)和sw(stripe width)
                            •   ZFS 非常适合备份管理
OS




                            •   CFQ适用于io大小非常均匀的场景
            I/O Scheduler   •   稍微复杂点的OLTP最好更换为 Deadline
                            •   I/O性能不是瓶颈的时候使用NOOP
                            •   Anticipatory不适用数据库场景




            CPU/DRAM
                  …




2012/4/16                                    35
MySQL 性能优化最佳实践
      方法


                            •   XFS 非常适合 MySQL
             File System    •   XFS要注意su(stripe size)和sw(stripe width)
                            •   ZFS 非常适合备份管理
OS




                            •   CFQ适用于io大小非常均匀的场景
            I/O Scheduler   •   稍微复杂点的OLTP最好更换为 Deadline
                            •   I/O性能不是瓶颈的时候使用NOOP
                            •   Anticipatory不适用数据库场景



                            •   提升 CPU 利用率
            CPU/DRAM        •   均衡 CPU 资源
                            •   提高内存利用率
                  …




2012/4/16                                    36
MySQL 性能优化最佳实践
      误区


                            •   XFS 非常适合 MySQL
             File System    •   XFS要注意su(stripe size)和sw(stripe width)
                            •   ZFS 非常适合备份管理
OS




                            •   CFQ适用于io大小非常均匀的场景
            I/O Scheduler   •   稍微复杂点的OLTP最好更换为 Deadline
                            •   I/O性能不是瓶颈的时候使用NOOP
                            •   Anticipatory不适用数据库场景



                            •   CPU越多越好?
            CPU/DRAM        •   NUMA 一定能提高性能?
                            •   内存越大越好?
                  …




2012/4/16                                    37
MySQL 性能优化最佳实践
   最佳实践


                            •   XFS 非常适合 MySQL
             File System    •   XFS要注意su(stripe size)和sw(stripe width)
                            •   ZFS 非常适合备份管理
OS




                            •   CFQ适用于io大小非常均匀的场景
            I/O Scheduler   •   稍微复杂点的OLTP最好更换为 Deadline
                            •   I/O性能不是瓶颈的时候使用NOOP
                            •   Anticipatory不适用数据库场景


                            •   单实例关闭 NUMA
            CPU/DRAM        •   CPU Core达到16最好双实例
                            •   多实例进行 CPU 绑定
                            •   单实例没必要超过64GB内存
                  …




2012/4/16                                    38
MySQL 性能优化最佳实践
         方法
                               •   query_cache:缓存结果集,极高效,与SQL语句一一对应
                               •   binlog_cache_size:缓存binlog数据,影响所有写入操作的性能
                               •   table_cache:缓存打开的表信息,MyISAM会占用较多,表多的需注意
                               •   thread_cache:缓存连接线程,影响连接建立效率,对短连接影响较大
             Cache/Buffer      •   key_buffer_size:缓存MyISAM索引,对MyISAM表性能影响极大
                               •   innodb_db_buffer_pool_size:对InnoDB极大影响,缓存索引及数据
                               •   innodb_log_buff_size:缓存InnoDB写入日志,影响写入效率
                               •   innodb_max_dirty_pages_pct:设置InnoDB Buffer中脏页占比
Params




              Connction




                   IO
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                      39
MySQL 性能优化最佳实践
         误区
                               •   query_cache:一定要有?越大越好?
                               •   binlog_cache_size:越大越好?
                               •   table_cache:越多越好?
                               •   thread_cache:越多越好?
             Cache/Buffer      •   key_buffer_size:缓存数据?越大越好?
                               •   innodb_db_buffer_pool_size:越大越好?
                               •   innodb_log_buff_size:越大越好?
                               •   innodb_max_dirty_pages_pct:脏页占比越多越快?
Params




              Connction




                   IO
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                      40
MySQL 性能优化最佳实践
     最佳实践
                               •   query_cache:不超过256MB,除非基本静态,InnoDB无效
                               •   binlog_cache_size:2MB~4MB,< 32MB
                               •   table_cache:1024,具体需要根据实际环境调整
                               •   thread_cache:1024,< max_connectios
             Cache/Buffer      •   key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大
                               •   innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大
                               •   innodb_log_buff_size:4MB~8MB,< 32MB
                               •   innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100
Params




              Connction




                   IO
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                        41
MySQL 性能优化最佳实践
         方法
                               •   query_cache:不超过256MB,除非基本静态,InnoDB无效
                               •   binlog_cache_size:2MB~4MB,< 32MB
                               •   table_cache:1024,具体需要根据实际环境调整
                               •   thread_cache:1024,< max_connectios
             Cache/Buffer      •   key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大
                               •   innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大
                               •   innodb_log_buff_size:4MB~8MB,< 32MB
                               •   innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100
Params




                               •   max_connections:影响能够保持的最大客户端连接数,属于自我保护类
              Connction        •   max_connect_errors:某个用户允许最大登录失败次数,类似于防破解
                               •   back_log:影响突发连接暴增场景,比如服务器重启后瞬间
                               •   skip-name-resolve:取消对客户端的 DNS 反解,影响连接和授权
                               •   interactive_timeout和wait_timeout:影响空闲连接最大可空闲时间



                   IO
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                        42
MySQL 性能优化最佳实践
         误区
                               •   query_cache:不超过256MB,除非基本静态,InnoDB无效
                               •   binlog_cache_size:2MB~4MB,< 32MB
                               •   table_cache:1024,具体需要根据实际环境调整
                               •   thread_cache:1024,< max_connectios
             Cache/Buffer      •   key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大
                               •   innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大
                               •   innodb_log_buff_size:4MB~8MB,< 32MB
                               •   innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100
Params




                               •   max_connections:最大连接数越大越好?
              Connction        •   max_connect_errors:最大错误数越小越好?
                               •   back_log:back log队列越长越好吗?
                               •   skip-name-resolve:一定要忽略 DNS 反解吗?
                               •   interactive_timeout和wait_timeout:空闲时间越长越好吗?



                   IO
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                        43
MySQL 性能优化最佳实践
     最佳实践
                               •   query_cache:不超过256MB,除非基本静态,InnoDB无效
                               •   binlog_cache_size:2MB~4MB,< 32MB
                               •   table_cache:1024,具体需要根据实际环境调整
                               •   thread_cache:1024,< max_connectios
             Cache/Buffer      •   key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大
                               •   innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大
                               •   innodb_log_buff_size:4MB~8MB,< 32MB
                               •   innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100
Params




                               •   max_connections:1000~2000,< 10000
              Connction        •   max_connect_errors:>1000,尽量大一点吧
                               •   back_log:100,< OS网络层设置
                               •   skip-name-resolve:建议启用,确保授权都是用IP
                               •   interactive_timeout和wait_timeout:86400,24小时基本足矣



                   IO
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                        44
MySQL 性能优化最佳实践
         方法
                               •   query_cache:不超过256MB,除非基本静态,InnoDB无效
                               •   binlog_cache_size:2MB~4MB,< 32MB
                               •   table_cache:1024,具体需要根据实际环境调整
                               •   thread_cache:1024,< max_connectios
             Cache/Buffer      •   key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大
                               •   innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大
                               •   innodb_log_buff_size:4MB~8MB,< 32MB
                               •   innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100
Params




                               •   max_connections:1000~2000,< 10000
              Connction        •   max_connect_errors:>1000,尽量大一点吧
                               •   back_log:100,< OS网络层设置
                               •   skip-name-resolve:建议启用,确保授权都是用IP
                               •   interactive_timeout和wait_timeout:86400,24小时基本足矣

                               •   innodb_flush_method:innodb文件打开方式,linux下文件系统影响较大
                   IO          •   innodb_flush_log_at_trx_commit:影响innodb日志事务刷新机制
                               •   innodb_file_per_table:影响表存储方式,文件过大会影响性能
                               •   sync_binlog:影响binlog日志刷新到磁盘的机制
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                        45
MySQL 性能优化最佳实践
         误区
                               •   query_cache:不超过256MB,除非基本静态,InnoDB无效
                               •   binlog_cache_size:2MB~4MB,< 32MB
                               •   table_cache:1024,具体需要根据实际环境调整
                               •   thread_cache:1024,< max_connectios
             Cache/Buffer      •   key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大
                               •   innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大
                               •   innodb_log_buff_size:4MB~8MB,< 32MB
                               •   innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100
Params




                               •   max_connections:1000~2000,< 10000
              Connction        •   max_connect_errors:>1000,尽量大一点吧
                               •   back_log:100,< OS网络层设置
                               •   skip-name-resolve:建议启用,确保授权都是用IP
                               •   interactive_timeout和wait_timeout:86400,24小时基本足矣

                               •   innodb_flush_method:注意系统之间的差异及文件系统差异
                   IO          •   innodb_flush_log_at_trx_commit:设为1最好吗?
                               •   innodb_file_per_table:独享表空间更好吗?
                               •   sync_binlog:刷新越频繁越好吗?
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                        46
MySQL 性能优化最佳实践
     最佳实践
                               •   query_cache:不超过256MB,除非基本静态,InnoDB无效
                               •   binlog_cache_size:2MB~4MB,< 32MB
                               •   table_cache:1024,具体需要根据实际环境调整
                               •   thread_cache:1024,< max_connectios
             Cache/Buffer      •   key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大
                               •   innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大
                               •   innodb_log_buff_size:4MB~8MB,< 32MB
                               •   innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100
Params




                               •   max_connections:1000~2000,< 10000
              Connction        •   max_connect_errors:>1000,尽量大一点吧
                               •   back_log:100,< OS网络层设置
                               •   skip-name-resolve:建议启用,确保授权都是用IP
                               •   interactive_timeout和wait_timeout:86400,24小时基本足矣

                               •   innodb_flush_method:O_DIRECT(Linux)
                   IO          •   innodb_flush_log_at_trx_commit:2,特别重要的设置为1,不建议0
                               •   innodb_file_per_table:一般建议开启
                               •   sync_binlog:4~8,非常频繁的系统可适当增大,但不建议0
                   …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter

2012/4/16                                        47
MySQL 性能优化最佳实践
                 方法

                               •   尽量索引,MyISAM只缓存索引不缓存数据
                               •   调整读写优先级,根据实际需求,调整读写优先级
                               •   延迟插入,使用 insert delay,减少和 select 竞争
Storage Engine




                               •   数据顺序操作,让insert全部到尾部,减少和select竞争
                      MyISAM   •   分解大操作,将大操作分解成多步小操作,防止长时间锁定
                               •   降低并发数,表锁会导致竞争激烈,通过排队机制提高效率
                               •   充分利用 Query Cache:对于静态数据,尽量使用 Query Cache
                               •   …




                      InnoDB
                       …




2012/4/16                                   48
MySQL 性能优化最佳实践
                 误区



                               •   key_buffer 会缓存所有 MyISAM 的数据和索引?
                               •   MyISAM 读写一定是互斥的?
Storage Engine




                      MyISAM   •   MyISAM 读效率一定高于 InnoDB?
                               •   在 MyISAM 中所有的 count 都高效?
                               •   …




                      InnoDB
                       …




2012/4/16                                   49
MySQL 性能优化最佳实践
            最佳实践



                          •   不需要事务支持
                          •   并发相对较低
Storage Engine




                 MyISAM   •   数据修改相对较少
                          •   以读为主
                          •   数据一致性要求较低
                          •   …




                 InnoDB
                   …




2012/4/16                           50
MySQL 性能优化最佳实践
                 方法



                                   •   不需要事务支持
                                   •   并发相对较低
Storage Engine




                      MyISAM       •   数据修改相对较少
                                   •   以读为主
                                   •   数据一致性要求较低
                                   •   …


                               •       主键尽可能小:所有非主键索引都需要存储主键
                               •       索引整合,减少冗余索引,降低数据量
                               •       避免全表扫描,因为会导致表锁
                      InnoDB   •       尽量自己控制事务,关闭 aotucommit
                               •       尽量缓存所有数据和索引
                               •       合理设置 innodb_flush_log_at_trx_commit
                               •       充分利用索引避开表锁
                       …




                               •       避免主键更新
                               •       …




2012/4/16                                         51
MySQL 性能优化最佳实践
                 误区



                                   •   不需要事务支持
                                   •   并发相对较低
Storage Engine




                      MyISAM       •   数据修改相对较少
                                   •   以读为主
                                   •   数据一致性要求较低
                                   •   …


                               •       Innodb_buffer_pool 只缓存索引?
                               •       任何情况下都是行锁?
                               •       事务越小越好?
                      InnoDB   •       日志刷新越快越好?
                               •       …
                       …




2012/4/16                                         52
MySQL 性能优化最佳实践
            最佳实践



                          •   不需要事务支持
                          •   并发相对较低
Storage Engine




                 MyISAM   •   数据修改相对较少
                          •   以读为主
                          •   数据一致性要求较低
                          •   …



                          •   需要事务支持
                          •   并发较大
                 InnoDB   •   数据变更比较频繁
                          •   数据一致性要求较高
                          •   硬件设备内存较大,远大于索引数据量
                          •   …
                   …




2012/4/16                           53
MySQL 性能优化最佳实践
         方法

                                 •   合理设置长度
                                 •   尽量避免使用lob字段
            优化数据类型               •   尽量使用更小的数据类型
                                 •   …


            调整字符编码
Schame




               适当拆分



               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      54
MySQL 性能优化最佳实践
         误区

                                 •   预留越长越好?
                                 •   INT(1) 代表存放1位长度的整数值?
            优化数据类型               •   MySQL能够高效处理各种数据类型?
                                 •   …


            调整字符编码
Schame




               适当拆分



               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      55
MySQL 性能优化最佳实践
     最佳实践

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET


            调整字符编码
Schame




               适当拆分



               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      56
MySQL 性能优化最佳实践
         方法

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   够用就可以,选择更小的字符集
            调整字符编码                   保证语言环境能够支持覆盖
Schame




                                 •
                                 •   …



               适当拆分



               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      57
MySQL 性能优化最佳实践
         误区

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   一定要整个 Server 统一?
            调整字符编码                   一定要全库统一?
Schame




                                 •
                                 •   一定要全表统一?



               适当拆分



               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      58
MySQL 性能优化最佳实践
     最佳实践

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   纯拉丁字符能表示的内容,没必要选择 latin1
            调整字符编码                   数据类型可精确到字段,极端情况下单独设置
Schame




                                 •
                                 •   确定不需要多语言,就没必要UNICODE类型



               适当拆分



               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      59
MySQL 性能优化最佳实践
         方法

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   纯拉丁字符能表示的内容,没必要选择 latin1
            调整字符编码                   数据类型可精确到字段,极端情况下单独设置
Schame




                                 •
                                 •   确定不需要多语言,就没必要UNICODE类型


                                 •   降低单条记录长度,使单个数据块中存放尽可
               适当拆分                  能多的纪录
                                 •   …



               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      60
MySQL 性能优化最佳实践
         误区

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   纯拉丁字符能表示的内容,没必要选择 latin1
            调整字符编码                   数据类型可精确到字段,极端情况下单独设置
Schame




                                 •
                                 •   确定不需要多语言,就没必要UNICODE类型


                                 •   数据表一定要和程序对象对应才叫合理的设
               适当拆分                  计?
                                 •   只要不在 select 子句中的字段就不会被访问?
                                 •   …


               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      61
MySQL 性能优化最佳实践
     最佳实践

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   纯拉丁字符能表示的内容,没必要选择 latin1
            调整字符编码                   数据类型可精确到字段,极端情况下单独设置
Schame




                                 •
                                 •   确定不需要多语言,就没必要UNICODE类型


                                 •   将不常使用的字段以及大字段拆分到独立附属
               适当拆分                  表中
                                 •   …



               适度冗余
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      62
MySQL 性能优化最佳实践
         方法

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   纯拉丁字符能表示的内容,没必要选择 latin1
            调整字符编码                   数据类型可精确到字段,极端情况下单独设置
Schame




                                 •
                                 •   确定不需要多语言,就没必要UNICODE类型


                                 •   将不常使用的字段以及大字段拆分到独立附属
               适当拆分                  表中
                                 •   …


                                 •   冗余常用字段,减少关联查询
               适度冗余              •   …
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      63
MySQL 性能优化最佳实践
         误区

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   纯拉丁字符能表示的内容,没必要选择 latin1
            调整字符编码                   数据类型可精确到字段,极端情况下单独设置
Schame




                                 •
                                 •   确定不需要多语言,就没必要UNICODE类型


                                 •   将不常使用的字段以及大字段拆分到独立附属
               适当拆分                  表中
                                 •   …


                                 •   严格遵循第三范式的设计才是最高效的设计?
               适度冗余              •   …
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      64
MySQL 性能优化最佳实践
     最佳实践

                                 •   避免DOUBLE,区分开 TINYINT / INT / BIGINT
                                 •   尽量避免TEXT,VARCHAR不要留过大缓冲
            优化数据类型               •   尽量TIMESTAMP,能用DATE不用DATETIME
                                 •   拒绝 LOB类型,可尝试 ENUM & SET

                                 •   纯拉丁字符能表示的内容,没必要选择 latin1
            调整字符编码                   数据类型可精确到字段,极端情况下单独设置
Schame




                                 •
                                 •   确定不需要多语言,就没必要UNICODE类型


                                 •   将不常使用的字段以及大字段拆分到独立附属
               适当拆分                  表中
                                 •   …


                                 •   被频繁引用且只能通过 Join 2张(或者更多)
               适度冗余                  表的方式才能得到的独立小字段,建议冗余
                                 •   …
                  …




            延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema

2012/4/16                                      65
MySQL 性能优化最佳实践
        方法

                                  •   提高过滤性
                                  •   降低索引的更新分裂
              合适的字段               •   避免无效索引
                                  •   非不得已不用外键


              合适的顺序
Index




              合适的比例



              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      66
MySQL 性能优化最佳实践
        误区

                                  •   只要在 Where 条件中就应该创建索引?
                                  •   只要创建了索引,就能被 SQL 使用?
              合适的字段               •   使用索引一定比不使用索引快?



              合适的顺序
Index




              合适的比例



              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      67
MySQL 性能优化最佳实践
    最佳实践                          •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)


              合适的顺序
Index




              合适的比例



              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      68
MySQL 性能优化最佳实践
        方法                        •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   提早过滤
              合适的顺序               •   减少排序
Index




              合适的比例



              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      69
MySQL 性能优化最佳实践
        误区                        •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   只要将where条件中的字段全部放在索引中就可
              合适的顺序                   以了?
                                      索引的顺序对 SQL 访问没有影响?
Index




                                  •



              合适的比例



              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      70
MySQL 性能优化最佳实践
    最佳实践                          •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   过滤性越高的字段需要越靠前
              合适的顺序               •   核心SQL覆盖索引,确保尽可能高效
                                      不干扰过滤前提下,排序字段进入索引
Index




                                  •
                                  •   多 SQL 综合考虑,重复利用索引


              合适的比例



              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      71
MySQL 性能优化最佳实践
        方法                        •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   过滤性越高的字段需要越靠前
              合适的顺序               •   核心SQL覆盖索引,确保尽可能高效
                                      不干扰过滤前提下,排序字段进入索引
Index




                                  •
                                  •   多 SQL 综合考虑,重复利用索引

                                  •   控制索引长度,尤其是较长的字符串字段
              合适的比例



              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      72
MySQL 性能优化最佳实践
        误区                        •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   过滤性越高的字段需要越靠前
              合适的顺序               •   核心SQL覆盖索引,确保尽可能高效
                                      不干扰过滤前提下,排序字段进入索引
Index




                                  •
                                  •   多 SQL 综合考虑,重复利用索引

                                  •   索引可以无限大?
              合适的比例               •   索引只能使用整个字段?




              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      73
MySQL 性能优化最佳实践
    最佳实践                          •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   过滤性越高的字段需要越靠前
              合适的顺序               •   核心SQL覆盖索引,确保尽可能高效
                                      不干扰过滤前提下,排序字段进入索引
Index




                                  •
                                  •   多 SQL 综合考虑,重复利用索引

                                  •   必须回表取数据时,字符字段前缀索引(8)
              合适的比例               •   不用回表取数据时,建议整个字段




              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      74
MySQL 性能优化最佳实践
        方法                        •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   过滤性越高的字段需要越靠前
              合适的顺序               •   核心SQL覆盖索引,确保尽可能高效
                                      不干扰过滤前提下,排序字段进入索引
Index




                                  •
                                  •   多 SQL 综合考虑,重复利用索引

                                  •   必须回表取数据时,字符字段前缀索引(8)
              合适的比例               •   不用回表取数据时,建议整个字段



                                  •   定期维护存在频繁增删改字段的索引
              合理的维护
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      75
MySQL 性能优化最佳实践
        误区                        •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   过滤性越高的字段需要越靠前
              合适的顺序               •   核心SQL覆盖索引,确保尽可能高效
                                      不干扰过滤前提下,排序字段进入索引
Index




                                  •
                                  •   多 SQL 综合考虑,重复利用索引

                                  •   必须回表取数据时,字符字段前缀索引(8)
              合适的比例               •   不用回表取数据时,建议整个字段



                                  •   索引不会出现碎片?
              合理的维护               •   索引会自动维护?
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      76
MySQL 性能优化最佳实践
    最佳实践                          •   给索引的字段设置默认值
                                  •   不要让含NULL的字段进入组合索引
                                  •   删除过滤性低的字段的索引,可能性能更差
                                  •   不能在索引字段上做运算,会失效
              合适的字段               •   避免频繁更新的字段进入索引,增加IO负担
                                  •   尽量覆盖索引(MySQL排序效率不高)

                                  •   过滤性越高的字段需要越靠前
              合适的顺序               •   核心SQL覆盖索引,确保尽可能高效
                                      不干扰过滤前提下,排序字段进入索引
Index




                                  •
                                  •   多 SQL 综合考虑,重复利用索引

                                  •   必须回表取数据时,字符字段前缀索引(8)
              合适的比例               •   不用回表取数据时,建议整个字段



                                  •   每月维护(重建)非核心表上的索引(可以的前提)
              合理的维护               •   每季/年维护核心表上的索引(可以的前提)
                  …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-index

2012/4/16                                      77
MySQL 性能优化最佳实践
      方法




                                  •   缩短访问的路径
                                      尽早过滤数据
SQL




                                  •
             调整执行计划               •   尽可能减少排序
                                  •   降低 SQL 复杂度
                                  •   避开 MySQL 优化器 Bug,比如子查询
                                  •   …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-sql

2012/4/16                                       78
MySQL 性能优化最佳实践
      误区




                                  •   count(1)和count(primary_key) 优于 count(*) ?
                                  •   count(column) 和 count(*) 一样 ?
                                  •   select a,b from … 比 select a,b,c from … 可以让
SQL




             调整执行计划                   数据库访问更少的数据量 ?
                                  •   order by 一定需要排序操作 ?
                                  •   执行计划中有 filesort 就会进行磁盘文件排序 ?
                                  •   …




            延伸阅读:http://isky000.com/database/mysql-performance-tuning-sql

2012/4/16                                       79
MySQL 性能优化最佳实践
   优化原则
                                  •   减少表连接,减少复杂 SQL,拆分成简单SQL
                                  •   减少排序:非必要不排序,利用索引排序,减少
                                      参与排序的记录数
                                  •   尽量避免 select *
                                  •   尽量用 join 代替子查询
                                  •   尽量少使用 or,使用 in 或者 union(union all) 代替
SQL




                                  •   尽量用 union all 代替 union
             调整执行计划
                                  •   尽量早的将无用数据过滤:选择更优的索引,先
                                      分页再Join…
                                  •   避免类型转换:索引失效
                                  •   优先优化高并发的 SQL,而不是执行频率低某些
                                      “大”SQL
                                  •   从全局出发优化,而不是片面调整
                                  •   尽可能对每一条SQL进行 explain
                                  •   …



            延伸阅读:http://isky000.com/database/mysql-performance-tuning-sql

2012/4/16                                       80
MySQL 性能优化最佳实践
     确认结果




                        OS
               top
               vmstat
               iostat
               …         确认




2012/4/16                    81
MySQL 性能优化最佳实践
     确认结果




                        OS        MySQL
               top
               vmstat              show status
               iostat
               …         确认




2012/4/16                    82
MySQL 性能优化最佳实践
     确认结果




                        OS          MySQL
               top
               vmstat                  show status
               iostat
               …         确认
                             App
                             latency
                             tps
                             …




2012/4/16                      83
MySQL 性能优化最佳实践




               Thanks,Q & A


                http://isky000.com
                Twitter:@sky000
                Weibo:@简朝阳




2012/4/16                84

More Related Content

What's hot

利用统一存储获得无与伦比的速度,简化系统,并节省更多
利用统一存储获得无与伦比的速度,简化系统,并节省更多利用统一存储获得无与伦比的速度,简化系统,并节省更多
利用统一存储获得无与伦比的速度,简化系统,并节省更多ITband
 
Sql server performance Tuning
Sql server performance TuningSql server performance Tuning
Sql server performance TuningSimon Huang
 
No sql带来了什么 孙立
No sql带来了什么   孙立No sql带来了什么   孙立
No sql带来了什么 孙立Shaoning Pan
 
阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践drewz lin
 
Oracle saa s paas overview
Oracle saa s paas overviewOracle saa s paas overview
Oracle saa s paas overviewChris Lee
 
数据库高可用架构
数据库高可用架构数据库高可用架构
数据库高可用架构freezr
 
构建基于Lamp的网站架构
构建基于Lamp的网站架构构建基于Lamp的网站架构
构建基于Lamp的网站架构Cosey Lee
 
SQL Server效能調校
SQL Server效能調校SQL Server效能調校
SQL Server效能調校國昭 張
 
高性能队列Fqueue的设计和使用实践
高性能队列Fqueue的设计和使用实践高性能队列Fqueue的设计和使用实践
高性能队列Fqueue的设计和使用实践孙立
 
深入了解Oracle自动内存管理asmm
深入了解Oracle自动内存管理asmm深入了解Oracle自动内存管理asmm
深入了解Oracle自动内存管理asmmmaclean liu
 
[译]No sql生态系统
[译]No sql生态系统[译]No sql生态系统
[译]No sql生态系统iammutex
 
服务器基准测试-叶金荣@CYOU-20121130
服务器基准测试-叶金荣@CYOU-20121130服务器基准测试-叶金荣@CYOU-20121130
服务器基准测试-叶金荣@CYOU-20121130Jinrong Ye
 
Oracle管理藝術第1章 在Linux作業體統安裝Oracle 11g
Oracle管理藝術第1章 在Linux作業體統安裝Oracle 11gOracle管理藝術第1章 在Linux作業體統安裝Oracle 11g
Oracle管理藝術第1章 在Linux作業體統安裝Oracle 11gChien Chung Shen
 
浅谈 My sql 性能调优
浅谈 My sql 性能调优浅谈 My sql 性能调优
浅谈 My sql 性能调优thinkinlamp
 
1号店数据库架构
1号店数据库架构1号店数据库架构
1号店数据库架构Louis liu
 
辽宁大学私有云项目分析
辽宁大学私有云项目分析辽宁大学私有云项目分析
辽宁大学私有云项目分析博 孟
 
浅谈电商网站数据访问层(DAL)与 ORM 之适用性
浅谈电商网站数据访问层(DAL)与 ORM 之适用性浅谈电商网站数据访问层(DAL)与 ORM 之适用性
浅谈电商网站数据访问层(DAL)与 ORM 之适用性Xuefeng Zhang
 

What's hot (19)

利用统一存储获得无与伦比的速度,简化系统,并节省更多
利用统一存储获得无与伦比的速度,简化系统,并节省更多利用统一存储获得无与伦比的速度,简化系统,并节省更多
利用统一存储获得无与伦比的速度,简化系统,并节省更多
 
Sql server performance Tuning
Sql server performance TuningSql server performance Tuning
Sql server performance Tuning
 
No sql带来了什么 孙立
No sql带来了什么   孙立No sql带来了什么   孙立
No sql带来了什么 孙立
 
阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践
 
Oracle saa s paas overview
Oracle saa s paas overviewOracle saa s paas overview
Oracle saa s paas overview
 
Oracle SGA 介紹
Oracle SGA 介紹Oracle SGA 介紹
Oracle SGA 介紹
 
数据库高可用架构
数据库高可用架构数据库高可用架构
数据库高可用架构
 
构建基于Lamp的网站架构
构建基于Lamp的网站架构构建基于Lamp的网站架构
构建基于Lamp的网站架构
 
SQL Server效能調校
SQL Server效能調校SQL Server效能調校
SQL Server效能調校
 
高性能队列Fqueue的设计和使用实践
高性能队列Fqueue的设计和使用实践高性能队列Fqueue的设计和使用实践
高性能队列Fqueue的设计和使用实践
 
深入了解Oracle自动内存管理asmm
深入了解Oracle自动内存管理asmm深入了解Oracle自动内存管理asmm
深入了解Oracle自动内存管理asmm
 
[译]No sql生态系统
[译]No sql生态系统[译]No sql生态系统
[译]No sql生态系统
 
服务器基准测试-叶金荣@CYOU-20121130
服务器基准测试-叶金荣@CYOU-20121130服务器基准测试-叶金荣@CYOU-20121130
服务器基准测试-叶金荣@CYOU-20121130
 
Oracle管理藝術第1章 在Linux作業體統安裝Oracle 11g
Oracle管理藝術第1章 在Linux作業體統安裝Oracle 11gOracle管理藝術第1章 在Linux作業體統安裝Oracle 11g
Oracle管理藝術第1章 在Linux作業體統安裝Oracle 11g
 
浅谈 My sql 性能调优
浅谈 My sql 性能调优浅谈 My sql 性能调优
浅谈 My sql 性能调优
 
1号店数据库架构
1号店数据库架构1号店数据库架构
1号店数据库架构
 
辽宁大学私有云项目分析
辽宁大学私有云项目分析辽宁大学私有云项目分析
辽宁大学私有云项目分析
 
内存数据库[1]
内存数据库[1]内存数据库[1]
内存数据库[1]
 
浅谈电商网站数据访问层(DAL)与 ORM 之适用性
浅谈电商网站数据访问层(DAL)与 ORM 之适用性浅谈电商网站数据访问层(DAL)与 ORM 之适用性
浅谈电商网站数据访问层(DAL)与 ORM 之适用性
 

Viewers also liked

浅谈数据库优化
浅谈数据库优化浅谈数据库优化
浅谈数据库优化Sky Jian
 
Oracle my sql-or-nosql
Oracle my sql-or-nosqlOracle my sql-or-nosql
Oracle my sql-or-nosqlSky Jian
 
MySQL Tuning For CPU Bottleneck
MySQL Tuning For CPU BottleneckMySQL Tuning For CPU Bottleneck
MySQL Tuning For CPU BottleneckSky Jian
 
MySQL Scalability Mistakes - OTN
MySQL Scalability Mistakes - OTNMySQL Scalability Mistakes - OTN
MySQL Scalability Mistakes - OTNRonald Bradford
 
The History and Future of the MySQL ecosystem
The History and Future of the MySQL ecosystemThe History and Future of the MySQL ecosystem
The History and Future of the MySQL ecosystemRonald Bradford
 
10x Performance Improvements - A Case Study
10x Performance Improvements - A Case Study10x Performance Improvements - A Case Study
10x Performance Improvements - A Case StudyRonald Bradford
 
Lessons Learned Managing Large AWS Environments
Lessons Learned Managing Large AWS EnvironmentsLessons Learned Managing Large AWS Environments
Lessons Learned Managing Large AWS EnvironmentsRonald Bradford
 
MySQL Backup and Recovery Essentials
MySQL Backup and Recovery EssentialsMySQL Backup and Recovery Essentials
MySQL Backup and Recovery EssentialsRonald Bradford
 
MySQL 8.0 & Unicode: Why, what & how
MySQL 8.0 & Unicode: Why, what & howMySQL 8.0 & Unicode: Why, what & how
MySQL 8.0 & Unicode: Why, what & howBernt Marius Johnsen
 
Monitoring your technology stack with New Relic
Monitoring your technology stack with New RelicMonitoring your technology stack with New Relic
Monitoring your technology stack with New RelicRonald Bradford
 
MySQL 8.0: GIS — Are you ready?
MySQL 8.0: GIS — Are you ready?MySQL 8.0: GIS — Are you ready?
MySQL 8.0: GIS — Are you ready?Norvald Ryeng
 
Proxysql use case scenarios fosdem17
Proxysql use case scenarios    fosdem17Proxysql use case scenarios    fosdem17
Proxysql use case scenarios fosdem17Alkin Tezuysal
 
Successful Scalability Principles - Part 1
Successful Scalability Principles - Part 1Successful Scalability Principles - Part 1
Successful Scalability Principles - Part 1Ronald Bradford
 
SQL window functions for MySQL
SQL window functions for MySQLSQL window functions for MySQL
SQL window functions for MySQLDag H. Wanvik
 
Real world #microservices with Apache Camel, Fabric8, and OpenShift
Real world #microservices with Apache Camel, Fabric8, and OpenShiftReal world #microservices with Apache Camel, Fabric8, and OpenShift
Real world #microservices with Apache Camel, Fabric8, and OpenShiftChristian Posta
 
MySQL 8.0: Common Table Expressions
MySQL 8.0: Common Table Expressions MySQL 8.0: Common Table Expressions
MySQL 8.0: Common Table Expressions oysteing
 
MySQL Server Defaults
MySQL Server DefaultsMySQL Server Defaults
MySQL Server DefaultsMorgan Tocker
 
What you wanted to know about MySQL, but could not find using inernal instrum...
What you wanted to know about MySQL, but could not find using inernal instrum...What you wanted to know about MySQL, but could not find using inernal instrum...
What you wanted to know about MySQL, but could not find using inernal instrum...Sveta Smirnova
 
MySQL设计、优化、运维
MySQL设计、优化、运维MySQL设计、优化、运维
MySQL设计、优化、运维Jinrong Ye
 
MySQL压力测试经验
MySQL压力测试经验MySQL压力测试经验
MySQL压力测试经验Jinrong Ye
 

Viewers also liked (20)

浅谈数据库优化
浅谈数据库优化浅谈数据库优化
浅谈数据库优化
 
Oracle my sql-or-nosql
Oracle my sql-or-nosqlOracle my sql-or-nosql
Oracle my sql-or-nosql
 
MySQL Tuning For CPU Bottleneck
MySQL Tuning For CPU BottleneckMySQL Tuning For CPU Bottleneck
MySQL Tuning For CPU Bottleneck
 
MySQL Scalability Mistakes - OTN
MySQL Scalability Mistakes - OTNMySQL Scalability Mistakes - OTN
MySQL Scalability Mistakes - OTN
 
The History and Future of the MySQL ecosystem
The History and Future of the MySQL ecosystemThe History and Future of the MySQL ecosystem
The History and Future of the MySQL ecosystem
 
10x Performance Improvements - A Case Study
10x Performance Improvements - A Case Study10x Performance Improvements - A Case Study
10x Performance Improvements - A Case Study
 
Lessons Learned Managing Large AWS Environments
Lessons Learned Managing Large AWS EnvironmentsLessons Learned Managing Large AWS Environments
Lessons Learned Managing Large AWS Environments
 
MySQL Backup and Recovery Essentials
MySQL Backup and Recovery EssentialsMySQL Backup and Recovery Essentials
MySQL Backup and Recovery Essentials
 
MySQL 8.0 & Unicode: Why, what & how
MySQL 8.0 & Unicode: Why, what & howMySQL 8.0 & Unicode: Why, what & how
MySQL 8.0 & Unicode: Why, what & how
 
Monitoring your technology stack with New Relic
Monitoring your technology stack with New RelicMonitoring your technology stack with New Relic
Monitoring your technology stack with New Relic
 
MySQL 8.0: GIS — Are you ready?
MySQL 8.0: GIS — Are you ready?MySQL 8.0: GIS — Are you ready?
MySQL 8.0: GIS — Are you ready?
 
Proxysql use case scenarios fosdem17
Proxysql use case scenarios    fosdem17Proxysql use case scenarios    fosdem17
Proxysql use case scenarios fosdem17
 
Successful Scalability Principles - Part 1
Successful Scalability Principles - Part 1Successful Scalability Principles - Part 1
Successful Scalability Principles - Part 1
 
SQL window functions for MySQL
SQL window functions for MySQLSQL window functions for MySQL
SQL window functions for MySQL
 
Real world #microservices with Apache Camel, Fabric8, and OpenShift
Real world #microservices with Apache Camel, Fabric8, and OpenShiftReal world #microservices with Apache Camel, Fabric8, and OpenShift
Real world #microservices with Apache Camel, Fabric8, and OpenShift
 
MySQL 8.0: Common Table Expressions
MySQL 8.0: Common Table Expressions MySQL 8.0: Common Table Expressions
MySQL 8.0: Common Table Expressions
 
MySQL Server Defaults
MySQL Server DefaultsMySQL Server Defaults
MySQL Server Defaults
 
What you wanted to know about MySQL, but could not find using inernal instrum...
What you wanted to know about MySQL, but could not find using inernal instrum...What you wanted to know about MySQL, but could not find using inernal instrum...
What you wanted to know about MySQL, but could not find using inernal instrum...
 
MySQL设计、优化、运维
MySQL设计、优化、运维MySQL设计、优化、运维
MySQL设计、优化、运维
 
MySQL压力测试经验
MySQL压力测试经验MySQL压力测试经验
MySQL压力测试经验
 

Similar to MySQL性能调优最佳实践

MySQL应用优化实践
MySQL应用优化实践MySQL应用优化实践
MySQL应用优化实践mysqlops
 
MySQL5.6新功能
MySQL5.6新功能MySQL5.6新功能
MySQL5.6新功能郁萍 王
 
4 葉金榮-my sql優化 - 20151219
4 葉金榮-my sql優化 - 201512194 葉金榮-my sql優化 - 20151219
4 葉金榮-my sql優化 - 20151219Ivan Tu
 
NoSQL误用和常见陷阱分析
NoSQL误用和常见陷阱分析NoSQL误用和常见陷阱分析
NoSQL误用和常见陷阱分析iammutex
 
Taobao数据库这5年
Taobao数据库这5年Taobao数据库这5年
Taobao数据库这5年yp_fangdong
 
MySQL Replication新功能介绍
MySQL Replication新功能介绍 MySQL Replication新功能介绍
MySQL Replication新功能介绍 orczhou
 
Sina my sq概述及优化
Sina my sq概述及优化Sina my sq概述及优化
Sina my sq概述及优化pigso
 
阿里集团MySQL并行复制特性
阿里集团MySQL并行复制特性阿里集团MySQL并行复制特性
阿里集团MySQL并行复制特性Hui Liu
 
2011 06-12-lamp-mysql-顾春江
2011 06-12-lamp-mysql-顾春江2011 06-12-lamp-mysql-顾春江
2011 06-12-lamp-mysql-顾春江thinkinlamp
 
2011 06-12-lamp-mysql
2011 06-12-lamp-mysql2011 06-12-lamp-mysql
2011 06-12-lamp-mysqlpwesh
 
性能优化
性能优化性能优化
性能优化Lu Wei
 
豆瓣网技术架构变迁
豆瓣网技术架构变迁豆瓣网技术架构变迁
豆瓣网技术架构变迁reinhardx
 
美丽说的架构发展与变迁 New
美丽说的架构发展与变迁 New美丽说的架构发展与变迁 New
美丽说的架构发展与变迁 New翀 刘
 
æ%A6%a9 my sql %f0%c8 -%c1%b8%cb+
æ%A6%a9 my sql %f0%c8 -%c1%b8%cb+æ%A6%a9 my sql %f0%c8 -%c1%b8%cb+
æ%A6%a9 my sql %f0%c8 -%c1%b8%cb+Cofyc
 
王龙:百度数据库架构演变与设计
王龙:百度数据库架构演变与设计王龙:百度数据库架构演变与设计
王龙:百度数据库架构演变与设计YANGL *
 
No sql应用场景及cassandra架构分析
No sql应用场景及cassandra架构分析No sql应用场景及cassandra架构分析
No sql应用场景及cassandra架构分析mysqlops
 
Mysql handlersocket
Mysql handlersocketMysql handlersocket
Mysql handlersocketpwesh
 
MySQL快速入门与提高
MySQL快速入门与提高MySQL快速入门与提高
MySQL快速入门与提高mysqlpub
 

Similar to MySQL性能调优最佳实践 (20)

MySQL应用优化实践
MySQL应用优化实践MySQL应用优化实践
MySQL应用优化实践
 
MySQL5.6新功能
MySQL5.6新功能MySQL5.6新功能
MySQL5.6新功能
 
Memlink
MemlinkMemlink
Memlink
 
MySQL调优
MySQL调优MySQL调优
MySQL调优
 
4 葉金榮-my sql優化 - 20151219
4 葉金榮-my sql優化 - 201512194 葉金榮-my sql優化 - 20151219
4 葉金榮-my sql優化 - 20151219
 
NoSQL误用和常见陷阱分析
NoSQL误用和常见陷阱分析NoSQL误用和常见陷阱分析
NoSQL误用和常见陷阱分析
 
Taobao数据库这5年
Taobao数据库这5年Taobao数据库这5年
Taobao数据库这5年
 
MySQL Replication新功能介绍
MySQL Replication新功能介绍 MySQL Replication新功能介绍
MySQL Replication新功能介绍
 
Sina my sq概述及优化
Sina my sq概述及优化Sina my sq概述及优化
Sina my sq概述及优化
 
阿里集团MySQL并行复制特性
阿里集团MySQL并行复制特性阿里集团MySQL并行复制特性
阿里集团MySQL并行复制特性
 
2011 06-12-lamp-mysql-顾春江
2011 06-12-lamp-mysql-顾春江2011 06-12-lamp-mysql-顾春江
2011 06-12-lamp-mysql-顾春江
 
2011 06-12-lamp-mysql
2011 06-12-lamp-mysql2011 06-12-lamp-mysql
2011 06-12-lamp-mysql
 
性能优化
性能优化性能优化
性能优化
 
豆瓣网技术架构变迁
豆瓣网技术架构变迁豆瓣网技术架构变迁
豆瓣网技术架构变迁
 
美丽说的架构发展与变迁 New
美丽说的架构发展与变迁 New美丽说的架构发展与变迁 New
美丽说的架构发展与变迁 New
 
æ%A6%a9 my sql %f0%c8 -%c1%b8%cb+
æ%A6%a9 my sql %f0%c8 -%c1%b8%cb+æ%A6%a9 my sql %f0%c8 -%c1%b8%cb+
æ%A6%a9 my sql %f0%c8 -%c1%b8%cb+
 
王龙:百度数据库架构演变与设计
王龙:百度数据库架构演变与设计王龙:百度数据库架构演变与设计
王龙:百度数据库架构演变与设计
 
No sql应用场景及cassandra架构分析
No sql应用场景及cassandra架构分析No sql应用场景及cassandra架构分析
No sql应用场景及cassandra架构分析
 
Mysql handlersocket
Mysql handlersocketMysql handlersocket
Mysql handlersocket
 
MySQL快速入门与提高
MySQL快速入门与提高MySQL快速入门与提高
MySQL快速入门与提高
 

More from Sky Jian

基于MySQL开放复制协议的同步扩展
基于MySQL开放复制协议的同步扩展基于MySQL开放复制协议的同步扩展
基于MySQL开放复制协议的同步扩展Sky Jian
 
基于 MySQL 的B2C电商系统前端数据层架构
基于 MySQL 的B2C电商系统前端数据层架构基于 MySQL 的B2C电商系统前端数据层架构
基于 MySQL 的B2C电商系统前端数据层架构Sky Jian
 
高可用可扩展数据层 - MySQL架构实践
高可用可扩展数据层 - MySQL架构实践高可用可扩展数据层 - MySQL架构实践
高可用可扩展数据层 - MySQL架构实践Sky Jian
 
MySQL Explain
MySQL Explain MySQL Explain
MySQL Explain Sky Jian
 
My sql cluster 基础
My sql cluster   基础My sql cluster   基础
My sql cluster 基础Sky Jian
 
高可用可扩展数据库架构方案探讨
高可用可扩展数据库架构方案探讨高可用可扩展数据库架构方案探讨
高可用可扩展数据库架构方案探讨Sky Jian
 
Life Of A Dirty Page Inno Db Disk Io
Life Of A Dirty Page Inno Db Disk IoLife Of A Dirty Page Inno Db Disk Io
Life Of A Dirty Page Inno Db Disk IoSky Jian
 
My Sql Performance In A Cloud
My Sql Performance In A CloudMy Sql Performance In A Cloud
My Sql Performance In A CloudSky Jian
 
Oracle Data Buffer Cache
Oracle Data Buffer CacheOracle Data Buffer Cache
Oracle Data Buffer CacheSky Jian
 

More from Sky Jian (9)

基于MySQL开放复制协议的同步扩展
基于MySQL开放复制协议的同步扩展基于MySQL开放复制协议的同步扩展
基于MySQL开放复制协议的同步扩展
 
基于 MySQL 的B2C电商系统前端数据层架构
基于 MySQL 的B2C电商系统前端数据层架构基于 MySQL 的B2C电商系统前端数据层架构
基于 MySQL 的B2C电商系统前端数据层架构
 
高可用可扩展数据层 - MySQL架构实践
高可用可扩展数据层 - MySQL架构实践高可用可扩展数据层 - MySQL架构实践
高可用可扩展数据层 - MySQL架构实践
 
MySQL Explain
MySQL Explain MySQL Explain
MySQL Explain
 
My sql cluster 基础
My sql cluster   基础My sql cluster   基础
My sql cluster 基础
 
高可用可扩展数据库架构方案探讨
高可用可扩展数据库架构方案探讨高可用可扩展数据库架构方案探讨
高可用可扩展数据库架构方案探讨
 
Life Of A Dirty Page Inno Db Disk Io
Life Of A Dirty Page Inno Db Disk IoLife Of A Dirty Page Inno Db Disk Io
Life Of A Dirty Page Inno Db Disk Io
 
My Sql Performance In A Cloud
My Sql Performance In A CloudMy Sql Performance In A Cloud
My Sql Performance In A Cloud
 
Oracle Data Buffer Cache
Oracle Data Buffer CacheOracle Data Buffer Cache
Oracle Data Buffer Cache
 

MySQL性能调优最佳实践

  • 1. MySQL 性能优化最佳实践 About me 简朝阳(sky000) Oracle ACE(Expertise: MySQL) 技术保障部 @麦包包 Blog:http://isky000.com Twitter:@sky000 Weibo:@简朝阳 2012/4/16 1
  • 2. MySQL 性能优化最佳实践 优化过程 找出瓶颈 确认结果 优化 设定目标 实施优化 2012/4/16 2
  • 3. MySQL 性能优化最佳实践 容量白菜价 2TB很普及 找出瓶颈 了 存储容量 瓶颈 2012/4/16 3
  • 4. MySQL 性能优化最佳实践 找出瓶颈 一般很难跑满 万兆已经很多 存储容量 Network(IOPS/吞吐量) 瓶颈 2012/4/16 4
  • 5. MySQL 性能优化最佳实践 找出瓶颈 存储容量 Linux单机支持过百 Network(IOPS/吞吐量) G 价格较之过去已大降 DRAM 瓶颈 2012/4/16 5
  • 6. MySQL 性能优化最佳实践 找出瓶颈 存储容量 Network(IOPS/吞吐量) X86 DRAM Nehalem,SMP,NUMA 4路 PC Server 32核 >30% CPU 瓶颈 2012/4/16 6
  • 7. MySQL 性能优化最佳实践 找出瓶颈 存储容量 Network(IOPS/吞吐量) DRAM CPU OLTP:iops OLAP:吞吐量 IO (IOPS/吞吐量) >60% 瓶颈在 IO 瓶颈 SSD? 2012/4/16 7
  • 8. MySQL 性能优化最佳实践 设定目标 极限不可 能突破 设备能力 目标 2012/4/16 8
  • 9. MySQL 性能优化最佳实践 设定目标 一切以需 极限不可 求为导向 能突破 设备能力 业务需求 目标 2012/4/16 9
  • 10. MySQL 性能优化最佳实践 设定目标 一切以需 极限不可 求为导向 能突破 设备能力 业务需求 目标 应用环境 环境影响 可行性 2012/4/16 10
  • 11. MySQL 性能优化最佳实践 实施优化 对象 Hardware OS Params Engine MySQL Schema Index SQL 实施 2012/4/16 11
  • 12. MySQL 性能优化最佳实践 实施优化 对象 方法 Hardware OS Params 方 Engine 法 … MySQL Schema Index SQL 实施 2012/4/16 12
  • 13. MySQL 性能优化最佳实践 实施优化 对象 方法 误区 Hardware OS Params 方 误 Engine 法 区 … … MySQL Schema Index SQL 实施 2012/4/16 13
  • 14. MySQL 性能优化最佳实践 实施优化 对象 方法 误区 最佳实践 Hardware OS Params 方 误 经 Engine 法 区 验 … … … MySQL Schema Index SQL 实施 2012/4/16 14
  • 15. MySQL 性能优化最佳实践 实施优化 转速,容量,接口 HDD: ~150 iops, < 200MB SSD: 10x ~ 1000x, < 400MB 磁盘 背景 2012/4/16 15
  • 16. MySQL 性能优化最佳实践 实施优化 主频,多核,超线程 SMP, NUMA, MPP 磁盘 CPU 背景 2012/4/16 16
  • 17. MySQL 性能优化最佳实践 实施优化 ~ Balance Tree 磁盘 CPU 缩短检索路径 有序 背景 索引 2012/4/16 17
  • 18. MySQL 性能优化最佳实践 实施优化 磁盘 CPU 背景 索引 SQL 执行计划 如何获得:explain 如何分析:Docs 2012/4/16 18
  • 19. MySQL 性能优化最佳实践 实施优化 磁盘 CPU 背景 索引 MySQL SQL 简单,轻型,开放 多线程,插件式 SQL+Storage Engine … 2012/4/16 19
  • 20. MySQL 性能优化最佳实践 实施优化 磁盘 CPU 存储引擎 背景 索引 插件式,可自由更换 开放型,可 自行开发 SQL 多样性,特性不一 MySQL 并存性,可并存使用 2012/4/16 20
  • 21. MySQL 性能优化最佳实践 方法 • 提高磁盘转速 Disk • 增加磁盘数量 • 选好磁盘接口 Hardware Raid Card CPU … 2012/4/16 21
  • 22. MySQL 性能优化最佳实践 误区 • 容量越大越好? Disk • FC磁盘一定比SAS盘快? • 磁盘 Cache 越大越好? Hardware Raid Card CPU … 2012/4/16 22
  • 23. MySQL 性能优化最佳实践 最佳实践 • OLTP: 小容量”高”转速 • OLAP: 大容量”低”转速(钱多可以高转 Disk 速) • 磁盘数量尽可能多 • 有钱可以上 SSD( IO 瓶颈场景下) Hardware Raid Card CPU … 2012/4/16 23
  • 24. MySQL 性能优化最佳实践 方法 • OLTP: 小容量”高”转速 • OLAP: 大容量”低”转速(钱多可以高转 Disk 速) • 磁盘数量尽可能多 • 有钱可以上 SSD( IO 瓶颈场景下) Hardware Raid Card • 增加Raid卡Cache容量 • 提升 Cache 利用率 • 确保数据安全 CPU … 2012/4/16 24
  • 25. MySQL 性能优化最佳实践 误区 • OLTP: 小容量”高”转速 • OLAP: 大容量”低”转速(钱多可以高转 Disk 速) • 磁盘数量尽可能多 • 有钱可以上 SSD( IO 瓶颈场景下) Hardware Raid Card • 读写都是用 Cache 提升效率? • Raid10一定比Raid5快? • 带电池的 Raid 卡数据一定安 全? CPU … 2012/4/16 25
  • 26. MySQL 性能优化最佳实践 最佳实践 • OLTP: 小容量”高”转速 • OLAP: 大容量”低”转速(钱多可以高转速) Disk • 磁盘数量尽可能多 • 有钱可以上 SSD( IO 瓶颈场景下) Hardware • Cache 只供写使用,Direct 读取 Raid Card • OLTP Raid10,Strip Size 参考DB • OLAP Raid5 • 关注 Raid 卡充放电带来的 Cache 失效 • 预读只对连续读有效,OLTP 关闭预读 CPU … 2012/4/16 26
  • 27. MySQL 性能优化最佳实践 方法 • OLTP: 小容量”高”转速 • OLAP: 大容量”低”转速(钱多可以高转 Disk 速) • 磁盘数量尽可能多 • 有钱可以上 SSD( IO 瓶颈场景下) Hardware • Cache 只供写使用,Direct 读取 Raid Card • OLTP Raid10,Strip Size 参考DB • OLAP Raid5 • 关注 Raid 卡充放电带来的 Cache 失效 • 预读只对连续读有效,OLTP 关闭预读 CPU • 提高CPU运算能力(频率?) • 缩短 CPU 访问数据的路径(缓存?) … 2012/4/16 27
  • 28. MySQL 性能优化最佳实践 误区 • OLTP: 小容量”高”转速 • OLAP: 大容量”低”转速(钱多可以高转 Disk 速) • 磁盘数量尽可能多 • 有钱可以上 SSD( IO 瓶颈场景下) Hardware • Cache 只供写使用,Direct 读取 Raid Card • OLTP Raid10,Strip Size 参考DB • OLAP Raid5 • 关注 Raid 卡充放电带来的 Cache 失效 • 预读只对连续读有效,OLTP 关闭预读 CPU • CPU 越多越好? • Core 越多越好? … 2012/4/16 28
  • 29. MySQL 性能优化最佳实践 最佳实践 • OLTP: 小容量”高”转速 • OLAP: 大容量”低”转速(钱多可以高转 Disk 速) • 磁盘数量尽可能多 • 有钱可以上 SSD( IO 瓶颈场景下) Hardware • Cache 只供写使用,Direct 读取 Raid Card • OLTP Raid10,Strip Size 参考DB • OLAP Raid5 • 关注 Raid 卡充放电带来的 Cache 失效 • 预读只对连续读有效,OLTP 关闭预读 • 使用主频更高的 CPU CPU • 使用缓存更大的 CPU • 8个Core 比较合适,不超过16 Core • Core比较多可以单机多实例 … 2012/4/16 29
  • 30. MySQL 性能优化最佳实践 方法 • 确保安全:有日志,能恢复 • OLTP: 提高大文件下随机I/O性能 File System • OLAP: 提高大文件下连续I/O性能 • 降低管理成本 OS I/O Scheduler CPU/DRAM … 2012/4/16 30
  • 31. MySQL 性能优化最佳实践 误区 • OS默认自带的就是最好的? File System • 功能最强的才是最好的? • 性能最高的才是最好的? OS I/O Scheduler CPU/DRAM … 2012/4/16 31
  • 32. MySQL 性能优化最佳实践 最佳实践 • XFS 非常适合 MySQL File System • XFS要注意su(stripe size)和sw(stripe width) • ZFS 非常适合备份管理 OS I/O Scheduler CPU/DRAM … 2012/4/16 32
  • 33. MySQL 性能优化最佳实践 方法 • XFS 非常适合 MySQL File System • XFS要注意su(stripe size)和sw(stripe width) • ZFS 非常适合备份管理 OS I/O Scheduler • 尽量减少不必要阻塞 • 尽量降低随机I/O访问的延时 • CFQ, Deadline,NOOP和Anticipatory 差异 CPU/DRAM … 2012/4/16 33
  • 34. MySQL 性能优化最佳实践 误区 • XFS 非常适合 MySQL File System • XFS要注意su(stripe size)和sw(stripe width) • ZFS 非常适合备份管理 OS I/O Scheduler • 公平的才是最合适的? • 智能的就是合适的? CPU/DRAM … 2012/4/16 34
  • 35. MySQL 性能优化最佳实践 最佳实践 • XFS 非常适合 MySQL File System • XFS要注意su(stripe size)和sw(stripe width) • ZFS 非常适合备份管理 OS • CFQ适用于io大小非常均匀的场景 I/O Scheduler • 稍微复杂点的OLTP最好更换为 Deadline • I/O性能不是瓶颈的时候使用NOOP • Anticipatory不适用数据库场景 CPU/DRAM … 2012/4/16 35
  • 36. MySQL 性能优化最佳实践 方法 • XFS 非常适合 MySQL File System • XFS要注意su(stripe size)和sw(stripe width) • ZFS 非常适合备份管理 OS • CFQ适用于io大小非常均匀的场景 I/O Scheduler • 稍微复杂点的OLTP最好更换为 Deadline • I/O性能不是瓶颈的时候使用NOOP • Anticipatory不适用数据库场景 • 提升 CPU 利用率 CPU/DRAM • 均衡 CPU 资源 • 提高内存利用率 … 2012/4/16 36
  • 37. MySQL 性能优化最佳实践 误区 • XFS 非常适合 MySQL File System • XFS要注意su(stripe size)和sw(stripe width) • ZFS 非常适合备份管理 OS • CFQ适用于io大小非常均匀的场景 I/O Scheduler • 稍微复杂点的OLTP最好更换为 Deadline • I/O性能不是瓶颈的时候使用NOOP • Anticipatory不适用数据库场景 • CPU越多越好? CPU/DRAM • NUMA 一定能提高性能? • 内存越大越好? … 2012/4/16 37
  • 38. MySQL 性能优化最佳实践 最佳实践 • XFS 非常适合 MySQL File System • XFS要注意su(stripe size)和sw(stripe width) • ZFS 非常适合备份管理 OS • CFQ适用于io大小非常均匀的场景 I/O Scheduler • 稍微复杂点的OLTP最好更换为 Deadline • I/O性能不是瓶颈的时候使用NOOP • Anticipatory不适用数据库场景 • 单实例关闭 NUMA CPU/DRAM • CPU Core达到16最好双实例 • 多实例进行 CPU 绑定 • 单实例没必要超过64GB内存 … 2012/4/16 38
  • 39. MySQL 性能优化最佳实践 方法 • query_cache:缓存结果集,极高效,与SQL语句一一对应 • binlog_cache_size:缓存binlog数据,影响所有写入操作的性能 • table_cache:缓存打开的表信息,MyISAM会占用较多,表多的需注意 • thread_cache:缓存连接线程,影响连接建立效率,对短连接影响较大 Cache/Buffer • key_buffer_size:缓存MyISAM索引,对MyISAM表性能影响极大 • innodb_db_buffer_pool_size:对InnoDB极大影响,缓存索引及数据 • innodb_log_buff_size:缓存InnoDB写入日志,影响写入效率 • innodb_max_dirty_pages_pct:设置InnoDB Buffer中脏页占比 Params Connction IO … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 39
  • 40. MySQL 性能优化最佳实践 误区 • query_cache:一定要有?越大越好? • binlog_cache_size:越大越好? • table_cache:越多越好? • thread_cache:越多越好? Cache/Buffer • key_buffer_size:缓存数据?越大越好? • innodb_db_buffer_pool_size:越大越好? • innodb_log_buff_size:越大越好? • innodb_max_dirty_pages_pct:脏页占比越多越快? Params Connction IO … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 40
  • 41. MySQL 性能优化最佳实践 最佳实践 • query_cache:不超过256MB,除非基本静态,InnoDB无效 • binlog_cache_size:2MB~4MB,< 32MB • table_cache:1024,具体需要根据实际环境调整 • thread_cache:1024,< max_connectios Cache/Buffer • key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大 • innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大 • innodb_log_buff_size:4MB~8MB,< 32MB • innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100 Params Connction IO … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 41
  • 42. MySQL 性能优化最佳实践 方法 • query_cache:不超过256MB,除非基本静态,InnoDB无效 • binlog_cache_size:2MB~4MB,< 32MB • table_cache:1024,具体需要根据实际环境调整 • thread_cache:1024,< max_connectios Cache/Buffer • key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大 • innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大 • innodb_log_buff_size:4MB~8MB,< 32MB • innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100 Params • max_connections:影响能够保持的最大客户端连接数,属于自我保护类 Connction • max_connect_errors:某个用户允许最大登录失败次数,类似于防破解 • back_log:影响突发连接暴增场景,比如服务器重启后瞬间 • skip-name-resolve:取消对客户端的 DNS 反解,影响连接和授权 • interactive_timeout和wait_timeout:影响空闲连接最大可空闲时间 IO … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 42
  • 43. MySQL 性能优化最佳实践 误区 • query_cache:不超过256MB,除非基本静态,InnoDB无效 • binlog_cache_size:2MB~4MB,< 32MB • table_cache:1024,具体需要根据实际环境调整 • thread_cache:1024,< max_connectios Cache/Buffer • key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大 • innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大 • innodb_log_buff_size:4MB~8MB,< 32MB • innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100 Params • max_connections:最大连接数越大越好? Connction • max_connect_errors:最大错误数越小越好? • back_log:back log队列越长越好吗? • skip-name-resolve:一定要忽略 DNS 反解吗? • interactive_timeout和wait_timeout:空闲时间越长越好吗? IO … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 43
  • 44. MySQL 性能优化最佳实践 最佳实践 • query_cache:不超过256MB,除非基本静态,InnoDB无效 • binlog_cache_size:2MB~4MB,< 32MB • table_cache:1024,具体需要根据实际环境调整 • thread_cache:1024,< max_connectios Cache/Buffer • key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大 • innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大 • innodb_log_buff_size:4MB~8MB,< 32MB • innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100 Params • max_connections:1000~2000,< 10000 Connction • max_connect_errors:>1000,尽量大一点吧 • back_log:100,< OS网络层设置 • skip-name-resolve:建议启用,确保授权都是用IP • interactive_timeout和wait_timeout:86400,24小时基本足矣 IO … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 44
  • 45. MySQL 性能优化最佳实践 方法 • query_cache:不超过256MB,除非基本静态,InnoDB无效 • binlog_cache_size:2MB~4MB,< 32MB • table_cache:1024,具体需要根据实际环境调整 • thread_cache:1024,< max_connectios Cache/Buffer • key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大 • innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大 • innodb_log_buff_size:4MB~8MB,< 32MB • innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100 Params • max_connections:1000~2000,< 10000 Connction • max_connect_errors:>1000,尽量大一点吧 • back_log:100,< OS网络层设置 • skip-name-resolve:建议启用,确保授权都是用IP • interactive_timeout和wait_timeout:86400,24小时基本足矣 • innodb_flush_method:innodb文件打开方式,linux下文件系统影响较大 IO • innodb_flush_log_at_trx_commit:影响innodb日志事务刷新机制 • innodb_file_per_table:影响表存储方式,文件过大会影响性能 • sync_binlog:影响binlog日志刷新到磁盘的机制 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 45
  • 46. MySQL 性能优化最佳实践 误区 • query_cache:不超过256MB,除非基本静态,InnoDB无效 • binlog_cache_size:2MB~4MB,< 32MB • table_cache:1024,具体需要根据实际环境调整 • thread_cache:1024,< max_connectios Cache/Buffer • key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大 • innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大 • innodb_log_buff_size:4MB~8MB,< 32MB • innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100 Params • max_connections:1000~2000,< 10000 Connction • max_connect_errors:>1000,尽量大一点吧 • back_log:100,< OS网络层设置 • skip-name-resolve:建议启用,确保授权都是用IP • interactive_timeout和wait_timeout:86400,24小时基本足矣 • innodb_flush_method:注意系统之间的差异及文件系统差异 IO • innodb_flush_log_at_trx_commit:设为1最好吗? • innodb_file_per_table:独享表空间更好吗? • sync_binlog:刷新越频繁越好吗? … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 46
  • 47. MySQL 性能优化最佳实践 最佳实践 • query_cache:不超过256MB,除非基本静态,InnoDB无效 • binlog_cache_size:2MB~4MB,< 32MB • table_cache:1024,具体需要根据实际环境调整 • thread_cache:1024,< max_connectios Cache/Buffer • key_buffer_size:无MyISAM 16MB,否则所有MYI大小之内尽可能大 • innodb_db_buffer_pool_size:仅InnoDB,所有文件大小之内尽可能大 • innodb_log_buff_size:4MB~8MB,< 32MB • innodb_max_dirty_pages_pct:<1G/innodb_db_buffer_pool_size(G)*100 Params • max_connections:1000~2000,< 10000 Connction • max_connect_errors:>1000,尽量大一点吧 • back_log:100,< OS网络层设置 • skip-name-resolve:建议启用,确保授权都是用IP • interactive_timeout和wait_timeout:86400,24小时基本足矣 • innodb_flush_method:O_DIRECT(Linux) IO • innodb_flush_log_at_trx_commit:2,特别重要的设置为1,不建议0 • innodb_file_per_table:一般建议开启 • sync_binlog:4~8,非常频繁的系统可适当增大,但不建议0 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 2012/4/16 47
  • 48. MySQL 性能优化最佳实践 方法 • 尽量索引,MyISAM只缓存索引不缓存数据 • 调整读写优先级,根据实际需求,调整读写优先级 • 延迟插入,使用 insert delay,减少和 select 竞争 Storage Engine • 数据顺序操作,让insert全部到尾部,减少和select竞争 MyISAM • 分解大操作,将大操作分解成多步小操作,防止长时间锁定 • 降低并发数,表锁会导致竞争激烈,通过排队机制提高效率 • 充分利用 Query Cache:对于静态数据,尽量使用 Query Cache • … InnoDB … 2012/4/16 48
  • 49. MySQL 性能优化最佳实践 误区 • key_buffer 会缓存所有 MyISAM 的数据和索引? • MyISAM 读写一定是互斥的? Storage Engine MyISAM • MyISAM 读效率一定高于 InnoDB? • 在 MyISAM 中所有的 count 都高效? • … InnoDB … 2012/4/16 49
  • 50. MySQL 性能优化最佳实践 最佳实践 • 不需要事务支持 • 并发相对较低 Storage Engine MyISAM • 数据修改相对较少 • 以读为主 • 数据一致性要求较低 • … InnoDB … 2012/4/16 50
  • 51. MySQL 性能优化最佳实践 方法 • 不需要事务支持 • 并发相对较低 Storage Engine MyISAM • 数据修改相对较少 • 以读为主 • 数据一致性要求较低 • … • 主键尽可能小:所有非主键索引都需要存储主键 • 索引整合,减少冗余索引,降低数据量 • 避免全表扫描,因为会导致表锁 InnoDB • 尽量自己控制事务,关闭 aotucommit • 尽量缓存所有数据和索引 • 合理设置 innodb_flush_log_at_trx_commit • 充分利用索引避开表锁 … • 避免主键更新 • … 2012/4/16 51
  • 52. MySQL 性能优化最佳实践 误区 • 不需要事务支持 • 并发相对较低 Storage Engine MyISAM • 数据修改相对较少 • 以读为主 • 数据一致性要求较低 • … • Innodb_buffer_pool 只缓存索引? • 任何情况下都是行锁? • 事务越小越好? InnoDB • 日志刷新越快越好? • … … 2012/4/16 52
  • 53. MySQL 性能优化最佳实践 最佳实践 • 不需要事务支持 • 并发相对较低 Storage Engine MyISAM • 数据修改相对较少 • 以读为主 • 数据一致性要求较低 • … • 需要事务支持 • 并发较大 InnoDB • 数据变更比较频繁 • 数据一致性要求较高 • 硬件设备内存较大,远大于索引数据量 • … … 2012/4/16 53
  • 54. MySQL 性能优化最佳实践 方法 • 合理设置长度 • 尽量避免使用lob字段 优化数据类型 • 尽量使用更小的数据类型 • … 调整字符编码 Schame 适当拆分 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 54
  • 55. MySQL 性能优化最佳实践 误区 • 预留越长越好? • INT(1) 代表存放1位长度的整数值? 优化数据类型 • MySQL能够高效处理各种数据类型? • … 调整字符编码 Schame 适当拆分 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 55
  • 56. MySQL 性能优化最佳实践 最佳实践 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET 调整字符编码 Schame 适当拆分 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 56
  • 57. MySQL 性能优化最佳实践 方法 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 够用就可以,选择更小的字符集 调整字符编码 保证语言环境能够支持覆盖 Schame • • … 适当拆分 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 57
  • 58. MySQL 性能优化最佳实践 误区 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 一定要整个 Server 统一? 调整字符编码 一定要全库统一? Schame • • 一定要全表统一? 适当拆分 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 58
  • 59. MySQL 性能优化最佳实践 最佳实践 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 纯拉丁字符能表示的内容,没必要选择 latin1 调整字符编码 数据类型可精确到字段,极端情况下单独设置 Schame • • 确定不需要多语言,就没必要UNICODE类型 适当拆分 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 59
  • 60. MySQL 性能优化最佳实践 方法 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 纯拉丁字符能表示的内容,没必要选择 latin1 调整字符编码 数据类型可精确到字段,极端情况下单独设置 Schame • • 确定不需要多语言,就没必要UNICODE类型 • 降低单条记录长度,使单个数据块中存放尽可 适当拆分 能多的纪录 • … 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 60
  • 61. MySQL 性能优化最佳实践 误区 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 纯拉丁字符能表示的内容,没必要选择 latin1 调整字符编码 数据类型可精确到字段,极端情况下单独设置 Schame • • 确定不需要多语言,就没必要UNICODE类型 • 数据表一定要和程序对象对应才叫合理的设 适当拆分 计? • 只要不在 select 子句中的字段就不会被访问? • … 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 61
  • 62. MySQL 性能优化最佳实践 最佳实践 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 纯拉丁字符能表示的内容,没必要选择 latin1 调整字符编码 数据类型可精确到字段,极端情况下单独设置 Schame • • 确定不需要多语言,就没必要UNICODE类型 • 将不常使用的字段以及大字段拆分到独立附属 适当拆分 表中 • … 适度冗余 … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 62
  • 63. MySQL 性能优化最佳实践 方法 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 纯拉丁字符能表示的内容,没必要选择 latin1 调整字符编码 数据类型可精确到字段,极端情况下单独设置 Schame • • 确定不需要多语言,就没必要UNICODE类型 • 将不常使用的字段以及大字段拆分到独立附属 适当拆分 表中 • … • 冗余常用字段,减少关联查询 适度冗余 • … … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 63
  • 64. MySQL 性能优化最佳实践 误区 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 纯拉丁字符能表示的内容,没必要选择 latin1 调整字符编码 数据类型可精确到字段,极端情况下单独设置 Schame • • 确定不需要多语言,就没必要UNICODE类型 • 将不常使用的字段以及大字段拆分到独立附属 适当拆分 表中 • … • 严格遵循第三范式的设计才是最高效的设计? 适度冗余 • … … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 64
  • 65. MySQL 性能优化最佳实践 最佳实践 • 避免DOUBLE,区分开 TINYINT / INT / BIGINT • 尽量避免TEXT,VARCHAR不要留过大缓冲 优化数据类型 • 尽量TIMESTAMP,能用DATE不用DATETIME • 拒绝 LOB类型,可尝试 ENUM & SET • 纯拉丁字符能表示的内容,没必要选择 latin1 调整字符编码 数据类型可精确到字段,极端情况下单独设置 Schame • • 确定不需要多语言,就没必要UNICODE类型 • 将不常使用的字段以及大字段拆分到独立附属 适当拆分 表中 • … • 被频繁引用且只能通过 Join 2张(或者更多) 适度冗余 表的方式才能得到的独立小字段,建议冗余 • … … 延伸阅读:http://isky000.com/database/mysql-perfornamce-tuning-schema 2012/4/16 65
  • 66. MySQL 性能优化最佳实践 方法 • 提高过滤性 • 降低索引的更新分裂 合适的字段 • 避免无效索引 • 非不得已不用外键 合适的顺序 Index 合适的比例 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 66
  • 67. MySQL 性能优化最佳实践 误区 • 只要在 Where 条件中就应该创建索引? • 只要创建了索引,就能被 SQL 使用? 合适的字段 • 使用索引一定比不使用索引快? 合适的顺序 Index 合适的比例 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 67
  • 68. MySQL 性能优化最佳实践 最佳实践 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) 合适的顺序 Index 合适的比例 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 68
  • 69. MySQL 性能优化最佳实践 方法 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 提早过滤 合适的顺序 • 减少排序 Index 合适的比例 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 69
  • 70. MySQL 性能优化最佳实践 误区 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 只要将where条件中的字段全部放在索引中就可 合适的顺序 以了? 索引的顺序对 SQL 访问没有影响? Index • 合适的比例 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 70
  • 71. MySQL 性能优化最佳实践 最佳实践 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 过滤性越高的字段需要越靠前 合适的顺序 • 核心SQL覆盖索引,确保尽可能高效 不干扰过滤前提下,排序字段进入索引 Index • • 多 SQL 综合考虑,重复利用索引 合适的比例 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 71
  • 72. MySQL 性能优化最佳实践 方法 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 过滤性越高的字段需要越靠前 合适的顺序 • 核心SQL覆盖索引,确保尽可能高效 不干扰过滤前提下,排序字段进入索引 Index • • 多 SQL 综合考虑,重复利用索引 • 控制索引长度,尤其是较长的字符串字段 合适的比例 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 72
  • 73. MySQL 性能优化最佳实践 误区 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 过滤性越高的字段需要越靠前 合适的顺序 • 核心SQL覆盖索引,确保尽可能高效 不干扰过滤前提下,排序字段进入索引 Index • • 多 SQL 综合考虑,重复利用索引 • 索引可以无限大? 合适的比例 • 索引只能使用整个字段? 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 73
  • 74. MySQL 性能优化最佳实践 最佳实践 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 过滤性越高的字段需要越靠前 合适的顺序 • 核心SQL覆盖索引,确保尽可能高效 不干扰过滤前提下,排序字段进入索引 Index • • 多 SQL 综合考虑,重复利用索引 • 必须回表取数据时,字符字段前缀索引(8) 合适的比例 • 不用回表取数据时,建议整个字段 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 74
  • 75. MySQL 性能优化最佳实践 方法 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 过滤性越高的字段需要越靠前 合适的顺序 • 核心SQL覆盖索引,确保尽可能高效 不干扰过滤前提下,排序字段进入索引 Index • • 多 SQL 综合考虑,重复利用索引 • 必须回表取数据时,字符字段前缀索引(8) 合适的比例 • 不用回表取数据时,建议整个字段 • 定期维护存在频繁增删改字段的索引 合理的维护 … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 75
  • 76. MySQL 性能优化最佳实践 误区 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 过滤性越高的字段需要越靠前 合适的顺序 • 核心SQL覆盖索引,确保尽可能高效 不干扰过滤前提下,排序字段进入索引 Index • • 多 SQL 综合考虑,重复利用索引 • 必须回表取数据时,字符字段前缀索引(8) 合适的比例 • 不用回表取数据时,建议整个字段 • 索引不会出现碎片? 合理的维护 • 索引会自动维护? … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 76
  • 77. MySQL 性能优化最佳实践 最佳实践 • 给索引的字段设置默认值 • 不要让含NULL的字段进入组合索引 • 删除过滤性低的字段的索引,可能性能更差 • 不能在索引字段上做运算,会失效 合适的字段 • 避免频繁更新的字段进入索引,增加IO负担 • 尽量覆盖索引(MySQL排序效率不高) • 过滤性越高的字段需要越靠前 合适的顺序 • 核心SQL覆盖索引,确保尽可能高效 不干扰过滤前提下,排序字段进入索引 Index • • 多 SQL 综合考虑,重复利用索引 • 必须回表取数据时,字符字段前缀索引(8) 合适的比例 • 不用回表取数据时,建议整个字段 • 每月维护(重建)非核心表上的索引(可以的前提) 合理的维护 • 每季/年维护核心表上的索引(可以的前提) … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-index 2012/4/16 77
  • 78. MySQL 性能优化最佳实践 方法 • 缩短访问的路径 尽早过滤数据 SQL • 调整执行计划 • 尽可能减少排序 • 降低 SQL 复杂度 • 避开 MySQL 优化器 Bug,比如子查询 • … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-sql 2012/4/16 78
  • 79. MySQL 性能优化最佳实践 误区 • count(1)和count(primary_key) 优于 count(*) ? • count(column) 和 count(*) 一样 ? • select a,b from … 比 select a,b,c from … 可以让 SQL 调整执行计划 数据库访问更少的数据量 ? • order by 一定需要排序操作 ? • 执行计划中有 filesort 就会进行磁盘文件排序 ? • … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-sql 2012/4/16 79
  • 80. MySQL 性能优化最佳实践 优化原则 • 减少表连接,减少复杂 SQL,拆分成简单SQL • 减少排序:非必要不排序,利用索引排序,减少 参与排序的记录数 • 尽量避免 select * • 尽量用 join 代替子查询 • 尽量少使用 or,使用 in 或者 union(union all) 代替 SQL • 尽量用 union all 代替 union 调整执行计划 • 尽量早的将无用数据过滤:选择更优的索引,先 分页再Join… • 避免类型转换:索引失效 • 优先优化高并发的 SQL,而不是执行频率低某些 “大”SQL • 从全局出发优化,而不是片面调整 • 尽可能对每一条SQL进行 explain • … 延伸阅读:http://isky000.com/database/mysql-performance-tuning-sql 2012/4/16 80
  • 81. MySQL 性能优化最佳实践 确认结果 OS top vmstat iostat … 确认 2012/4/16 81
  • 82. MySQL 性能优化最佳实践 确认结果 OS MySQL top vmstat show status iostat … 确认 2012/4/16 82
  • 83. MySQL 性能优化最佳实践 确认结果 OS MySQL top vmstat show status iostat … 确认 App latency tps … 2012/4/16 83
  • 84. MySQL 性能优化最佳实践 Thanks,Q & A http://isky000.com Twitter:@sky000 Weibo:@简朝阳 2012/4/16 84