本文整理了一些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 Interleaving，避免NUMA问题；
…
[获取更多]一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发。简单说，在master上是并发模式（以InnoDB引擎为主）完成事务提交的，而在slave上，复制线程只有一个sql thread用于binlog的apply，所以难怪slave在高并发时会远落后master。
ORACLE MySQL 5.6版本开始支持多线程复制，配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制。不过，它只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slave还是没有办法及时追上master，需要想办法进行优化。
…
[获取更多]
备注：插图来自discuz!官方LOGO，如果觉得不当还请及时告知 ：）
写在前面：discuz!作为首屈一指的社区系统，为广大站长提供了一站式网站解决方案，而且是开源的（虽然部分代码是加密的），它为这个垂直领域的行业发展作出了巨大贡献。尽管如此，discuz!系统源码中，还是或多或少有些坑。其中最著名的就是默认采用MyISAM引擎，以及基于MyISAM引擎的抢楼功能，session表采用memory引擎等，可以参考后面几篇历史文章。本次我们要说说discuz!在应对热们帖子翻页逻辑功能中的另一个问题。
在我们的环境中，使用的是 MySQL-5.6.6 版本。
在查看帖子并翻页过程中，会产生类似下面这样的SQL：
mysql> desc …[获取更多]
篇首语：
截止到目前的5.7.4版本为止，MySQL的联合索引仍无法支持联合索引使用不同排序规则，例如：ALTER
TABLE t ADD INDEX idx(col1, col2 DESC)。
先来了解下MySQL关于索引的一些基础知识要点：
• a、EXPLAIN结果中的key_len只显示了条件检索子句需要的索引长度，但 ORDER BY、GROUP BY 子句用到的索引则不计入 key_len 统计值； • b、联合索引(composite index)：多个字段组成的索引，称为联合索引； 例如：ALTER TABLE t ADD INDEX `idx` (col1, col2, col3) • c、覆盖索引(covering index)：如果查询需要读取到索引中的一个或多个字段，则可以从索引树中直接取得结果集，称为覆盖索引； 例如：SELECT col1, col2 FROM t; • d、最左原则(prefix …[获取更多]
我们先了解下InnoDB引擎表的一些关键特征：
…
[获取更多]Query Cache（查询缓存，以下简称QC）存储SELECT语句及其产生的数据结果，特别适用于：频繁提交同一个语句，并且该表数据变化不是很频繁的场景，例如一些静态页面，或者页面中的某块不经常发生变化的信息。QC有可能会从InnoDB Buffer Pool或者MyISAM key buffer里读取结果。
由于QC需要缓存最新数据结果，因此表数据发生任何变化（INSERT、UPDATE、DELETE或其他可能产生数据变化的操作），都会导致QC被刷新。
根据MySQL官方的测试，QC的优劣分别是：
…[获取更多]
最近碰到一个慢SQL问题，解决过程有点小曲折，和大家分享下。 SQL本身不复杂，表结构、索引也比较简单，不过个别字段存在于多个索引中。
CREATE TABLE `pre_forum_post` ( `pid` int(10) unsigned NOT NULL, `fid` mediumint(8) unsigned NOT NULL DEFAULT '0', `tid` mediumint(8) unsigned NOT NULL DEFAULT '0', `first` tinyint(1) NOT NULL DEFAULT '0', `author` varchar(40) NOT NULL DEFAULT '', `authorid` int(10) unsigned NOT NULL DEFAULT '0', `subject` varchar(80) NOT NULL DEFAULT '', `dateline` int(10) unsigned NOT NULL DEFAULT '0', `message` mediumtext NOT NULL, `useip` varchar(15) NOT NULL DEFAULT '', `invisible` tinyint(1) NOT NULL DEFAULT '0', `anonymous` tinyint(1) NOT NULL DEFAULT '0', `usesig` tinyint(1) NOT NULL DEFAULT '0', `htmlon` tinyint(1) NOT NULL DEFAULT '0', `bbcodeoff` tinyint(1) NOT NULL DEFAULT '0', `smileyoff` tinyint(1) NOT NULL DEFAULT '0', `parseurloff` tinyint(1) NOT NULL …[获取更多]
个人最近几年内整理过的PPT，都放在百度文库上了，大家可以看看 ：）
MySQL tpch测试工具简要手册 高效Linux SA PC服务器阵列卡管理简易手册 服务器基准测试 MySQL数据库设计、优化 …
[获取更多]通常，我们会采用ORDER BY LIMIT start, offset 的方式来进行分页查询。例如下面这个SQL：
SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10;
或者像下面这个不带任何条件的分页SQL：
SELECT * FROM `t1` ORDER BY id DESC LIMIT 100, 10;
一般而言，分页SQL的耗时随着 start 值的增加而急剧增加，我们来看下面这2个不同起始值的分页SQL执行耗时：
yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 500, 10; … 10 rows in set (0.05 sec) yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=6 ORDER BY id DESC LIMIT 935500, 10; … 10 rows in set (2.39 sec)
可以看到，随着分页数量的增加，SQL查询耗时也有数十倍增加，显然不科学。今天我们就来分析下，如何能优化这个分页方案。 …
[获取更多]
众所周知，在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
1、常量等值检索：
…[获取更多]
