本文整理了一些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的query cache大部分情况下其实只是鸡肋而已，建议全面禁用。当然了，或许在你的场景下还是挺好的，还能发挥作用，那就继续使用吧，把本文当做参考就好。
不过，可能有的人人为只需要把 query_cache_size 大小调整为 0 就可以了，可以忽略 query_cache_type 参数的值，反正它也是可以在线调整的。
事实果真如此吗？让我们来实际模拟测试下就知道了。
我们模拟了以下几种场景：
1、初始化时，同时设置 query_cache_size 和 query_cache_type 的值为 0； …[获取更多]
持续可用
本文主要针对金融数据库，认为金融数据库的持续可用包含两点：一个是强一致性；另外一个是高可用性。
数据库系统必须是强一致性的系统，这是因为数据库系统有事务ACID的基本要求，而弱一致系统无法做到。业内也有一些流行的NOSQL系统，例如各种类Dynamo系统，如开源的Cassandra，对同一个最小数据单位(同一行数据)允许多台服务器同时写入，虽然采用NWR机制处理冲突，但是由于不可能解决多台服务器之间的时序问题，而只能支持弱一致语义。弱一致语义的问题很多，例如无法支持复杂功能，无法构建严谨的测试体系，无法应用到核心场景。虽然弱一致性系统也有一定的应用场景，但本文认为其不符合核心业务持续可用的要求，不予讨论。
…
[获取更多]我们在工作中时常会遇到一些客户的TPS\QPS都不太高,但磁盘占用非常大,一旦单实例空间太大，像内存、网络、CPU以及备份都将增加相应的开销。可能仅仅是由于空间不满足使得我们不得不进行扩容，下面的方法提供给大家参考。有则改之无则加勉。
1、表结构设计上
1) 字符集是否遵循了最小化原则?(能用latin的就不用gbk。能用gbk的就不用utf8)
2) 索引上是否有滥用？(根本不使用的字段建索引、不适合建索引的字段建索引、重复建索引或者不能很好的利用前缀索引等)
3) 冗余字段是否太多？(各表中不用的或者字段冗余太多)
4) 不正确的字段类型？(能用1个字节非要用几个字节，像枚举类、状态类比较常见)
5) …
[获取更多]今天一个朋友向我咨询怎么去优化 MySQL，我按着思维整理了一下，大概粗的可以分为21个方向。 还有一些细节东西(table cache, 表设计，索引设计，程序端缓存之类的)先不列了，对一个系统，初期能把下面做完也是一个不错的系统。
1. 要确保有足够的内存
数据库能够高效的运行，最关建的因素需要内存足更大了，能缓存住数据，更新也可以在内存先完成。但不同的业务对内存需要强度不一样，一推荐内存要占到数据的15-25%的比例，特别的热的数据，内存基本要达到数据库的80%大小。
2. 需要更多更快的CPU
MySQL 5.6可以利用到64个核，而MySQL每个query只能运行在一个CPU上，所以要求更多的CPU，更快的CPU会更有利于并发。
3. 要选择合适的操作系统
…
[获取更多]一个用户工单:数据从ECS迁移到RDS，相同的语句，查询性能下降了几十倍。而实际上RDS这个实例在内存上的配置与原来ECS上的实例相当。
本文简单说明这个case的原因及建议。
用户反馈性能变慢的语句为 (修改了真实表名和列名)
select count(1) from HR hr join H h on h.hid = hr.hid
join A e on e.aid = h.eid
join A t on t.aid = e.pid
join A c on c.aid = t.pid
join A p on p.aid = c.pid
left join U u on u.uid = hr.uId
left join E emp on emp.eid = hr.oid
where ( hr.s in (1,2,3,4) and hr.cn = 0 );
背景
…
[获取更多]众所周知，在MySQL中，如果直接 ORDER BY RAND() 的话，效率非常差，因为会多次执行。事实上，如果等值查询也是用 RAND() 的话也如此，我们先来看看下面这几个SQL的不同执行计划和执行耗时。
首先，看下建表DDL，这是一个没有显式自增主键的InnoDB表：
[yejr@imysql]> show create table t_innodb_random\G *************************** 1. row *************************** Table: t_innodb_random Create Table: CREATE TABLE `t_innodb_random` ( `id` int(10) unsigned NOT NULL, `user` varchar(64) NOT NULL DEFAULT '', KEY `idx_id` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1
往这个表里灌入一些测试数据，至少10万以上， id 字段也是乱序的。
[yejr@imysql]> select count(*) from t_innodb_random\G *************************** 1. row *************************** count(*): 393216
…
[获取更多]