MySQL性能调优最佳实践.ppt

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