本文整理了一些MySQL的通用优化方法，做个简单的总结分享，旨在帮助那些没有专职MySQL DBA的企业做好基本的优化工作，至于具体的SQL优化，大部分通过加适当的索引即可达到效果，更复杂的就需要具体分析了，可以参考本站的一些优化案例或者联系我，下方有我的联系方式。这是下篇。
3、MySQL层相关优化 3.1、关于版本选择
官方版本我们称为ORACLE MySQL，这个没什么好说的，相信绝大多数人会选择它。
我个人强烈建议选择Percona分支版本，它是一个相对比较成熟的、优秀的MySQL分支版本，在性能提升、可靠性、管理型方面做了不少改善。它和官方ORACLE MySQL版本基本完全兼容，并且性能大约有20%以上的提升，因此我优先推荐它，我自己也从2008年一直以它为主。
…
[获取更多]本文整理了一些MySQL的通用优化方法，做个简单的总结分享，旨在帮助那些没有专职MySQL DBA的企业做好基本的优化工作，至于具体的SQL优化，大部分通过加适当的索引即可达到效果，更复杂的就需要具体分析了，可以参考本站的一些优化案例或者联系我，下方有我的联系方式。这是上篇。
1、硬件层相关优化 1.1、CPU相关
在服务器的BIOS设置中，可调整下面的几个配置，目的是发挥CPU最大性能，或者避免经典的NUMA问题：
1、选择Performance Per Watt Optimized(DAPC)模式，发挥CPU最大性能，跑DB这种通常需要高运算量的服务就不要考虑节电了； 2、关闭C1E和C States等选项，目的也是为了提升CPU效率； 3、Memory Frequency(内存频率)选择Maximum Performance(最佳性能)； 4、内存设置菜单中，启用Node …[获取更多]
备注：插图来自discuz!官方LOGO，如果觉得不当还请及时告知 ：)
写在前面：discuz!作为首屈一指的社区系统，为广大站长提供了一站式网站解决方案，而且是开源的(虽然部分代码是加密的)，它为这个垂直领域的行业发展作出了巨大贡献。尽管如此，discuz!系统源码中，还是或多或少有些坑。其中最著名的就是默认采用MyISAM引擎，以及基于MyISAM引擎的抢楼功能，session表采用memory引擎等，可以参考后面几篇历史文章。本次我们要说说discuz!在应对热们帖子翻页逻辑功能中的另一个问题。
在我们的环境中，使用的是 MySQL-5.6.6 版本。
在查看帖子并翻页过程中，会产生类似下面这样的SQL：
mysql> desc SELECT * FROM pre_forum_post WHERE
tid=8201301 AND `invisible` IN('0','-2') ORDER BY dateline DESC LIMIT 15\G …[获取更多]
接续上一篇：
MySQL子查询优化---目标列中的子查询执行情况分析
http://blog.163.com/li_hx/blog/static/18399141320154291133386/
7
mysql> select (select max(a) from t as t2) from t as t1;
+------------------------------+
| (select max(a) from t as t2) |
+------------------------------+
|
2 |
|
2 |
+------------------------------+
问题就这样又来了：究竟这个示例中的子查询，会被执行几次？ …
[获取更多]备注：插图来自淘宝苏普的博客并保留水印，如果觉得不当还请及时告知 ：)
写在前面：MySQL的query cache大部分情况下其实只是鸡肋而已，建议全面禁用。当然了，或许在你的场景下还是挺好的，还能发挥作用，那就继续使用吧，把本文当做参考就好。
不过，可能有的人人为只需要把 query_cache_size 大小调整为 0 就可以了，可以忽略 query_cache_type 参数的值，反正它也是可以在线调整的。
事实果真如此吗？让我们来实际模拟测试下就知道了。
我们模拟了以下几种场景：
1、初始化时，同时设置 query_cache_size 和 query_cache_type 的值为 0； …[获取更多]
问题 当前，绝大多数业务场景用InnoDB已经完全能搞定了，越来越多的业务从MyISAM转向InnoDB引擎，那么有哪些注意事项呢？ 分析 当了解完两种引擎的不同之处，很轻松的就能知道有哪些关键点了。
总的来说，从MyISAM转向InnoDB的注意事项有：
1、MyISAM的主键索引中，可以在非第一列(非第一个字段)使用自增列，而InnoDB的主键索引中包含自增列时，必须在最前面；这个特性在discuz论坛中，被设计用于“抢楼”功能，因此，若有类似的业务，则无法将该表从MyISAM转成InnoDB，需要自行变通实现(我们则是将其改到Redis中实现)； 2、不带条件频繁统计全表总记录数时(SELECT COUNT(*) FROM TAB)，InnoDB相对较慢，而MyISAM则飞快；不过，如果是基于索引条件的统计，则二者相差不大； …[获取更多]
写在前面：我们在使用mysqldump备份数据时，请一定记住要加上 -q 参数，后果可能是很严重的，不要给自己挖坑哦。到底为什么呢，且听我慢慢道来！
先来看看 mysqldump -help 中，关于 -q 参数的解释：
-q, --quick Don't buffer query, dump directly to stdout.
简言之，就是说加上 -q 后，不会把SELECT出来的结果放在buffer中，而是直接dump到标准输出中，顶多只是buffer当前行结果，正常情况下是不会超过 max_allowed_packet 限制的，它默认情况下是开启的。
如果关闭该参数，则会把SELECT出来的结果放在本地buffer中，然后再输出给客户端，会消耗更多内存。
…
[获取更多][…] http://mysqllover.com/?p=1264 […]
MySQL的自动提交默认是开启的，用惯了Oracle，习惯了自己去提交或回滚。我们可以通过set来设置autocommit，过程如下：
Step 1：使用select @@autocommit来查看当前autocommit设置情况，如下图1：
图1：查看autocommit
1表示自动提交是开启的，0表示自动提交是关闭的，图1可看出，当前是处于开启状态。
Step 2：通过set autocommit = 0来关闭autocommit，如下图2：
图2：设置autocommit
还有别的方法来设置，目前我只用了上面的方法。
猜您喜欢
实际上本次故障的素材来自于朋友的朋友，虽然我并不是故障的亲身经历者，但即便只是作为旁观者，依然感觉有所收获，于是乎记录下来以馈读者。
故障的来龙去脉大致是这样的：在一个月黑风高的晚上，苦逼的程序员被一阵急促的报警短信声惊醒，原来是数据库的某个表出问题了，虽然查询操作都正常，但创建操作却都失败了，经过调试，发现原因是表被插入了一行问题数据，其自增字段的值被显式的设置为整型的最大值，导致后续缺省插入的数据不能获取到一个合法的主键值。
我们不妨创建一个测试表说明问题：
CREATE TABLE IF NOT EXISTS `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB;
然后插入一行问题数据：
INSERT …[获取更多]
