关于MySQL 优化的100个的建议

MySQL是一个功能强大的开源数据库。随着越来越多的数据库驱动的应用程序,人们一直在推动MySQL发展到它的极限。这里是100条调节和优化MySQL安装的技巧。一些技巧是针对特定的安装环境的,但这些思路是通用的。我已经把他们分成几类,来帮助你掌握更多MySQL的调节和优化技巧。

  MySQL 服务器硬件和操作系统调节:

  1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中——在内存中访问文件时的速度要比在硬盘中访问时快的多。

  2. 不惜一切代价避免使用Swap交换分区 – 交换时是从硬盘读取的,它的速度很慢。

  3. 使用电池供电的RAM(注:RAM即随机存储器)。

  4. 使用高级的RAID(注:Redundant Arrays of Inexpensive Disks,即磁盘阵列) – 最好是RAID10或更高。

  5. 避免RAID5(注:一种存储性能、数据安全和存储成本兼顾的存储解决方案) – 确保数据库完整性的校验是要付出代价的。

  6. 将操作系统和数据分区分开,不仅仅是逻辑上,还包括物理上– 操作系统的读写操作会影响数据库的性能。

  7. 把MySQL临时空间和复制日志与数据放到不同的分区– 当数据库后台从磁盘进行读写操作时会影响数据库的性能。

  8. 更多的磁盘空间等于更快的速度。

  9. 更好更快的磁盘。

  10. 使用SAS(注: Serial Attached SCSI,即串行连接SCSI)代替SATA(注:SATA,即串口硬盘)。

  11. 较小的硬盘 比 较大的硬盘快,尤其是在RAID配置的情况下。

  12. 使用电池支持的高速缓存RAID控制器。

  13. 避免使用软件磁盘阵列。

  14. 考虑为数据分区使用固态IO卡 (不是磁盘驱动器) – 这些卡能够为几乎任何数量的数据支持2GB/s的写入速度。

  15. 在Linux中设置swappiness的值为0 – 在数据库服务器中没有理由缓存文件,这是一个服务器或台式机的优势。

  16. 如果可以的话,使用 noatime 和 nodirtime挂载文件系统 – 没有理由更新访问数据库文件的修改时间。

  17. 使用 XFS 文件系统 – 一种比ext3更快、更小的文件系统,并且有许多日志选项, 而且ext3 已被证实与MySQL有双缓冲问题。

  18. 调整 XFS 文件系统日志和缓冲变量 – 为了最高性能标准。

  19. 在 Linux 系统中, 使用 NOOP 或者 DEADLINE IO 定时调度程序 – 同 NOOP 和 DEADLINE定时调度程序相比,这个 CFQ 和 ANTICIPATORY 定时调度程序 显得非常慢。

  20. 使用64位的操作系统 – 对于MySQL,会有更大的内存支持和使用。

  21. 删除服务器上未使用的安装包和守护进程– 更少的资源占用。

  22. 把使用MySQL的host和你的MySQL host放到一个hosts文件中 – 没有DNS查找。

  23. 切勿强制杀死一个MySQL进程 – 你会损坏数据库和正在运行备份的程序。

  24. 把服务器贡献给MySQL – 后台进程和其他服务能够缩短数据库占用CPU的时间。

  MySQL 配置:

  25. 当写入时,使用 innodb_flush_method=O_DIRECT 来避免双缓冲。

  26. 避免使用 O_DIRECT 和 EXT3 文件系统 – 你将序列化所有要写入的。

  27. 分配足够的 innodb_buffer_pool_size 来加载整个 InnoDB 文件到内存中– 少从磁盘中读取。

  28. 不要将 innodb_log_file_size 参数设置太大, 这样可以更快同时有更多的磁盘空间 – 丢掉多的日志通常是好的,在数据库崩溃后可以降低恢复数据库的时间。

  29. 不要混用 innodb_thread_concurrency 和 thread_concurrency 参数– 这2个值是不兼容的。

  30. 分配一个极小的数量给 max_connections 参数 – 太多的连接会用尽RAM并锁定MySQL服务。

  31. 保持 thread_cache 在一个相对较高的数字,大约 16 – 防止打开连接时缓慢。

  32. 使用skip-name-resolve参数 – 去掉 DNS 查找。

  33.如果你的查询都是重复的,并且数据不常常发生变化,那么可以使用查询缓存。但是如果你的数据经常发生变化,那么使用查询缓存会让你感到失望。\

  34.增大temp_table_size值,以防止写入磁盘

  35.增大max_heap_table_size值,以防止写入磁盘

  36.不要把sort_buffer_size值设置的太高,否则的话你的内存将会很快耗尽

  37.根据key_read_requests和key_reads值来决定key_buffer的大小,一般情况下key_read_requests应该比key_reads值高,否则你不能高效的使用key_buffer

  38.将innodb_flush_log_at_trx_commit设置为0将会提高性能,但是如果你要保持默认值(1)的话,那么你就要确保数据的完整性,同时你也要确保复制不会滞后。

  39.你要有一个测试环境,来测试你的配置,并且在不影响正常生产的情况下,可以常常进行重启。

  MySQL模式优化:

  40. 保持你的数据库整理性。

  41. 旧数据归档 - 删除多余的行返回或搜索查询。

  42. 将您的数据加上索引.

  43. 不要过度使用索引,比较与查询.

  44. 压缩文字和BLOB数据类型 - 以节省空间和减少磁盘读取次数.

  45. UTF 8和UTF16都低于latin1执行效率.

  46. 有节制地使用触发器.

  47. 冗余数据保持到最低限度 - 不重复不必要的数据.

  48. 使用链接表,而不是扩展行.

  49. 注意数据类型,在您的真实数据中,尽可能使用最小的一个.

  50. 如果其他数据经常被用于查询时,而BLOB / TEXT数据不是,就把BLOB / TEXT数据从其他数据分离出来.

  51.检查和经常优化表.

  52. 经常重写InnoDB表优化.

  53. 有时,当添加列时删除索引,然后在添加回来索引,这样就会更快.

  54. 针对不同的需求,使用不同的存储引擎.

  55. 使用归档存储引擎日志表或审计表-这是更有效地写道.

  56.会话数据存储在缓存(memcache)的而不是MySQL中 - 缓存允许自动自动填值的,并阻止您创建难以读取和写入到MySQL的时空数据.

  57.存储可变长度的字符串时使用VARCHAR而不是CHAR - 节省空间,因为固定长度的CHAR,而VARCHAR长度不固定(UTF8不受此影响).

  58. 逐步进行模式的变化 - 一个小的变化,可以有巨大的影响.

  59.在开发环境中测试所有模式,反映生产变化.

  60.不要随意更改你的配置文件中的值,它可以产生灾难性的影响.

  61.有时候,在MySQL的configs少即是多.

  62.有疑问时使用一个通用的MySQL配置文件.

  查询优化:

  63. 使用慢查询日志去发现慢查询。

  64. 使用执行计划去判断查询是否正常运行。

  65. 总是去测试你的查询看看是否他们运行在最佳状态下 –久而久之性能总会变化。

  66. 避免在整个表上使用count(*),它可能锁住整张表。

  67. 使查询保持一致以便后续相似的查询可以使用查询缓存。

  68. 在适当的情形下使用GROUP BY而不是DISTINCT。

  69. 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。

  70. 保持索引简单,不在多个索引中包含同一个列。

  71. 有时候MySQL会使用错误的索引,对于这种情况使用USE INDEX。

  72. 检查使用SQL_MODE=STRICT的问题。

  73. 对于记录数小于5的索引字段,在UNION的时候使用LIMIT不是是用OR.

  74. 为了 避免在更新前SELECT,使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去实现。

  75. 不要使用 MAX,使用索引字段和ORDER BY子句。

  76. 避免使用ORDER BY RAND().

  77。LIMIT M,N实际上可以减缓查询在某些情况下,有节制地使用。

  78。在WHERE子句中使用UNION代替子查询。

  79。对于UPDATES(更新),使用 SHARE MODE(共享模式),以防止独占锁。

  80。在重新启动的MySQL,记得来温暖你的数据库,以确保您的数据在内存和查询速度快。

  81。使用DROP TABLE,CREATE TABLE DELETE FROM从表中删除所有数据。

  82。最小化的数据在查询你需要的数据,使用*消耗大量的时间。

  83。考虑持久连接,而不是多个连接,以减少开销。

  84。基准查询,包括使用服务器上的负载,有时一个简单的查询可以影响其他查询。

  85。当负载增加您的服务器上,使用SHOW PROCESSLIST查看慢的和有问题的查询。

  86。在开发环境中产生的镜像数据中 测试的所有可疑的查询。

  MySQL 备份过程:

  87. 从二级复制服务器上进行备份。

  88. 在进行备份期间停止复制,以避免在数据依赖和外键约束上出现不一致。

  89. 彻底停止MySQL,从数据库文件进行备份。

  90. 如果使用 MySQL dump进行备份,请同时备份二进制日志文件– 确保复制没有中断。

  91. 不要信任LVM 快照 – 这很可能产生数据不一致,将来会给你带来麻烦。

  92. 为了更容易进行单表恢复,以表为单位导出数据 – 如果数据是与其他表隔离的。

  93. 当使用mysqldump时请使用 –opt。

  94. 在备份之前检查和优化表。

  95. 为了更快的进行导入,在导入时临时禁用外键约束。

  96. 为了更快的进行导入,在导入时临时禁用唯一性检测。

  97. 在每一次备份后计算数据库,表以及索引的尺寸,以便更够监控数据尺寸的增长。

  98. 通过自动调度脚本监控复制实例的错误和延迟。

  99. 定期执行备份。

  100. 定期测试你的备份。

(0)

相关推荐

  • MySQL数据表损坏的正确修复方案

    于断电或非正常关机而导致MySQL(和PHP搭配之最佳组合)数据库出现错误是非常常见的问题.有两种方法,一种方法使用MySQL(和PHP搭配之最佳组合)的check table和repair table 的sql语句,另一种方法是使用MySQL(和PHP搭配之最佳组合)提供的多个myisamchk, isamchk数据检测恢复工具.前者使用起来比较简便.推荐使用. 1. check table 和 repair table 登陆MySQL(和PHP搭配之最佳组合) 终端: MySQL(和PHP搭

  • Mysql性能优化案例研究-覆盖索引和SQL_NO_CACHE

    场景 产品中有一张图片表pics,数据量将近100万条,有一条相关的查询语句,由于执行频次较高,想针对此语句进行优化 表结构很简单,主要字段: 复制代码 代码如下: user_id 用户ID picname 图片名称 smallimg 小图名称 一个用户会有多条图片记录,现在有一个根据user_id建立的索引:uid,查询语句也很简单:取得某用户的图片集合: 复制代码 代码如下: select picname, smallimg from pics where user_id = xxx; 优化

  • MYSQL数据表损坏的原因分析和修复方法小结(推荐)

    1.表损坏的原因分析 以下原因是导致mysql 表毁坏的常见原因: 1. 服务器突然断电导致数据文件损坏. 2. 强制关机,没有先关闭mysql 服务. 3. mysqld 进程在写表时被杀掉. 4. 使用myisamchk 的同时,mysqld 也在操作表. 5. 磁盘故障. 6. 服务器死机. 7. mysql 本身的bug . 2.表损坏的症状 一个损坏的表的典型症状如下: 1 .当在从表中选择数据之时,你得到如下错误: Incorrect key file for table: '...

  • MySQL数据库修复方法(MyISAM/InnoDB)

    在网上找了篇MySQL的技术文章,感觉不错,把它翻译过来共享下.   原文作者:Mike Peters   我整理了7条修复MySQL数据库的方法,当简单的重启对数据库不起作用,或者有表崩溃时.   简单的MySQL重启:   /usr/local/mysql/bin/mysqladmin -uUSERNAME -pPASSWORD shutdown /usr/local/mysql/bin/mysqld_safe &    1.MyISAM表崩溃    MySQL数据库允许不同的表使用不同的存

  • MySQL数据库表修复 MyISAM

    一:MySQL中MyISAM表损坏原因总结: 1. 服务器突然断电导致数据文件损坏;强制关机,没有先关闭mysql 服务;mysqld 进程在写表时被杀掉. 2. 磁盘损坏. 3. 服务器死机. 4. mysql 本身的bug . 二:MySQL中MyISAM表损坏的症状总结: 1 .查询数据时报出错误:Incorrect key file for table: '...'. Try to repair it 2 .查询不能在表中找到行或返回不完全的数据. 3 .Error: Table '..

  • mysql表优化、分析、检查和修复的方法详解

    本文实例讲述了mysql表优化.分析.检查和修复的方法.分享给大家供大家参考,具体如下: 这里介绍对数据库的管理常规就是进行预防性的维护,以及修复那些出现问题的内容. 进行检查和修复通常具有四个主要的任务: 1. 对表进行优化 2. 对表进行分析(分析并存储MyISAM和BDB表中键的分布) 3. 对表进行检查(检查表的错误,并且为MyISAM更新键的统计内容) 4. 对表进行修复(修复被破坏的MyISAM表) 一.对表进行优化 优化表有很多方式实现: OPTIMIZE TABLE语句.mysq

  • mysql下优化表和修复表命令使用说明(REPAIR TABLE和OPTIMIZE TABLE)

    查询mysql表是否被损坏命令,如下: # CHECK TABLE 表名 mysql的长期使用,肯定会出现一些问题,一般情况下mysql表无法访问,就可以修复表了,优化时减少磁盘占用空间.方便备份. 表修复和优化命令,如下: #REPAIR TABLE `table_name` 修复表 #OPTIMIZE TABLE `table_name` 优化表 REPAIR TABLE 用于修复被破坏的表. OPTIMIZE TABLE 用于回收闲置的数据库空间,当表上的数据行被删除时,所占据的磁盘空间并

  • 教您修复mysql数据库的方法

    会mysql的朋友都知道mysql在长时间使用过后数据库会出现一些问题,这就需要快速修复损坏mysql数据库以方便我们的工作和学习.下面小编为大家下面介绍两种快速检修 MySQL 数据库的方法. 本人常用这样的代码,直接放到mysql数据库目录里面 复制代码 代码如下: cmd /k myisamchk -r jb51_tablename jb51_tablename是jb51_tablename.MYD的名称.运行以下就可以了. 有的时候因为掉电或者其他原因导致数据库损坏,我们可以使用mysq

  • MySQL中主从复制重复键问题修复方法

    -------------------quote begin------------------------ 3. If you decide that you can skip the next statement from the master, issue the following statements: mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n; mysql> START SLAVE; The value of n should be

  • mysql数据库索引损坏及修复经验分享

    mysql表索引被破坏的问题及解决 下午上班,惊闻我的dedecms的网站出问题了,访问一看,果然全屏报错,检查mysql日志,错误信息为: Table '.\dedecmsv4\dede_archives' is marked as crashed and should be repaired 提示说cms的文章表dede_archives被标记有问题,需要修复.于是赶快恢复历史数据,上网查找原因.最终将问题解决.解决方法如下: 找到mysql的安装目录的bin/myisamchk工具,在命令

  • Jemalloc优化MySQL和Nginx

    jemalloc源于Jason Evans 2006年在BSDcan conference发表的论文:<A Scalable Concurrent malloc Implementation for FreeBSD>.jason认为phkmalloc(FreeBSD's previous malloc implementation by Kamp (1998))没有考虑多处理器的情况,因此在多线程并发下性能低下(事实如此),而jemalloc适合多线程下内存分配管理.从2007年开始以Free

  • Mysql数据库之索引优化

    MySQL凭借着出色的性能.低廉的成本.丰富的资源,已经成为绝大多数互联网公司的首选关系型数据库.虽然性能出色,但所谓"好马配好鞍",如何能够更好的使用它,已经成为开发工程师的必修课,我们经常会从职位描述上看到诸如"精通MySQL"."SQL语句优化"."了解数据库原理"等要求.我们知道一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,

  • MySQL数据库INNODB表损坏修复处理过程分享

    突然收到MySQL报警,从库的数据库挂了,一直在不停的重启,打开错误日志,发现有张表坏了.innodb表损坏不能通过repair table 等修复myisam的命令操作.现在记录下解决过程,下次遇到就不会这么手忙脚乱了. 处理过程: 一遇到报警之后,直接打开错误日志,里面的信息: InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 30506. InnoDB: You may have t

随机推荐