1.单表优化
除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度。
一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。
而事实上很多时候 MySQL 单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量。
1.1字段
关于字段：
尽量使用 TINYINT、SMALLINT、MEDIUM_INT 作为整数类型而非 INT，如果非负则加上 UNSIGNED。
VARCHAR 的长度只分配真正需要的空间。
使用枚举或整数代替字符串类型。
尽量使用 TIMESTAMP 而非 DATETIME。
单表不要有太多字段，建议在 20 以内。
避免使用 NULL 字段，很难查询优化且占用额外索引空间。
用整型来存 IP。
1.2索引
关于索引：
索引并不是越多越好，要根据查询有针对性的创建，考虑在 WHERE 和 ORDER BY 命令上涉及的列建立索引，可根据 EXPLAIN 来查看是否用了索引还是全表扫描。
应尽量避免在 WHERE 子句中对字段进行 NULL 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
值分布很稀少的字段不适合建索引，例如“性别”这种只有两三个值的字段。
字符字段只建前缀索引。
字符字段最好不要做主键。
不用外键，由程序保证约束。
尽量不用 UNIQUE，由程序保证约束。
使用多列索引时注意顺序和查询条件保持一致，同时删除不必要的单列索引。
1.3查询 SQL
关于查询 SQL：
可通过开启慢查询日志来找出较慢的 SQL。
不做列运算：SELECT id WHERE age + 1 = 10，任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
SQL 语句尽可能简单：一条 SQL只能在一个 CPU 运算；大语句拆小语句，减少锁时间；一条大 SQL 可以堵死整个库。
不用SELECT *。
OR 改写成 IN：OR 的效率是 n 级别，IN 的效率是 log(n) 级别，IN 的个数建议控制在 200 以内。
不用函数和触发器，在应用程序实现。
避免 %xxx 式查询。
少用 JOIN。
使用同类型进行比较，比如用 '123' 和 '123' 比，123 和 123 比。
尽量避免在 WHERE 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。
对于连续数值，使用 BETWEEN 不用 IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5。
列表数据不要拿全表，要使用 LIMIT 来分页，每页数量也不要太大。
1.4引擎
目前广泛使用的是 MyISAM 和 InnoDB 两种引擎：
MyISAM
MyISAM 引擎是 MySQL 5.1 及之前版本的默认引擎，它的特点是：
不支持行锁，读取时对需要读到的所有表加锁，写入时则对表加排它锁。
不支持事务。
不支持外键。
不支持崩溃后的安全恢复。
在表有读取查询的同时，支持往表中插入新纪录。
支持 BLOB 和 TEXT 的前 500 个字符索引，支持全文索引。
支持延迟更新索引，极大提升写入性能。
对于不会进行修改的表，支持压缩表，极大减少磁盘空间占用。
InnoDB
InnoDB 在 MySQL 5.5 后成为默认索引，它的特点是：
支持行锁，采用 MVCC 来支持高并发。
支持事务。
支持外键。
支持崩溃后的安全恢复。
不支持全文索引。
PS：据说 InnoDB 已经在 MySQL 5.6.4 支持全文索引了。
总体来讲，MyISAM 适合 SELECT 密集型的表，而 InnoDB 适合 INSERT 和 UPDATE 密集型的表。
1.5系统调优参数
可以使用下面几个工具来做基准测试：
sysbench：一个模块化，跨平台以及多线程的性能测试工具。
https://github.com/akopytov/sysbench
iibench-mysql：基于 Java 的 MySQL / Percona / MariaDB 索引进行插入性能测试工具。
https://github.com/tmcallaghan/iibench-mysql
tpcc-mysql：Percona 开发的 TPC-C 测试工具。
https://github.com/Percona-Lab/tpcc-mysql
调优参数内容较多，具体可参考官方文档，这里介绍一些比较重要的参数：
back_log：back_log 值可以指出在 MySQL 暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。
也就是说，如果 MySQL 的连接数据达到 max_connections 时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即 back_log，
如果等待连接的数量超过 back_log，将不被授予连接资源。可以从默认的 50 升至 500。
wait_timeout：数据库连接闲置时间，闲置连接会占用内存资源。可以从默认的 8 小时减到半小时。
max_user_connection：最大连接数，默认为 0 无上限，最好设一个合理上限。
thread_concurrency：并发线程数，设为 CPU 核数的两倍。
skip_name_resolve：禁止对外部连接进行 DNS 解析，消除 DNS 解析时间，但需要所有远程主机用 IP 访问。
key_buffer_size：索引块的缓存大小，增加会提升索引处理速度，对 MyISAM 表性能影响最大。
对于内存 4G 左右，可设为 256M 或 384M，通过查询 show status like 'key_read%'，保证 key_reads / key_read_requests 在 0.1% 以下最好。
innodb_buffer_pool_size：缓存数据块和索引块，对 InnoDB 表性能影响最大。
通过查询 show status like 'Innodb_buffer_pool_read%'，保证 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests 越高越好。
innodb_additional_mem_pool_size：InnoDB 存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小。
当数据库对象非常多的时候，适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率，当过小的时候，MySQL 会记录 Warning
信息到数据库的错误日志中，这时就需要调整这个参数大小。
innodb_log_buffer_size：InnoDB 存储引擎的事务日志所使用的缓冲区，一般来说不建议超过 32MB。
query_cache_size：缓存 MySQL 中的 ResultSet，也就是一条 SQL 语句执行的结果集，所以仅仅只能针对 Select 语句。
当某个表的数据有任何变化，都会导致所有引用了该表的 Select 语句在 Query Cache 中的缓存数据失效。
所以，当我们数据变化非常频繁的情况下，使用 Query Cache 可能得不偿失。
根据命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))进行调整，一般不建议太大，256MB 可能已经差不多了，大型的配置型静态数据可适当调大。
可以通过命令 show status like 'Qcache_%' 查看目前系统 Query Cache 使用大小。
read_buffer_size：MySQL 读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySQL 会为它分配一段内存缓冲区。
如果对表的顺序扫描请求非常频繁，可以通过增加该变量值以及内存缓冲区大小提高其性能。
sort_buffer_size：MySQL 执行排序使用的缓冲大小。如果想要增加 ORDER BY 的速度，首先看是否可以让 MySQL 使用索引而不是额外的排序阶段。
如果不能，可以尝试增加 sort_buffer_size 变量的大小。
read_rnd_buffer_size：MySQL 的随机读缓冲区大小。当按任意顺序读取行时(例如按照排序顺序)，将分配一个随机读缓存区。
进行排序查询时，MySQL 会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。
但 MySQL 会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。
record_buffer：每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描，可能想要增加该值。
thread_cache_size：保存当前没有与连接关联但是准备为后面新的连接服务的线程，可以快速响应连接的线程请求而无需创建新的。
table_cache：类似于 thread_cache _size，但用来缓存表文件，对 InnoDB 效果不大，主要用于 MyISAM。
1.6升级硬件
Scale Up，这个不多说了，根据 MySQL 是 CPU 密集型还是 I/O 密集型，通过提升 CPU 和内存、使用 SSD，都能显著提升 MySQL 性能。
2.0读写分离
也是目前常用的优化，从库读主库写，一般不要采用双主或多主引入很多复杂性，尽量采用文中的其他方案来提高性能。同时目前很多拆分的解决方案
同时也兼顾考虑了读写分离。
3.0缓存
缓存可以发生在这些层次：
MySQL 内部：在系统调优参数介绍了相关设置。
数据访问层：比如 MyBatis 针对 SQL 语句做缓存，而 Hibernate 可以精确到单个记录，这里缓存的对象主要是持久化对象 Persistence Object。
应用服务层：可以通过编程手段对缓存做到更精准的控制和更多的实现策略，这里缓存的对象是数据传输对象 Data Transfer Object。
Web 层：针对 Web 页面做缓存。
浏览器客户端：用户端的缓存。
可以根据实际情况在一个层次或多个层次结合加入缓存。这里重点介绍下服务层的缓存实现。
目前主要有两种方式：
直写式（Write Through）：在数据写入数据库后，同时更新缓存，维持数据库与缓存的一致性。
这也是当前大多数应用缓存框架如 Spring Cache 的工作方式。这种实现非常简单，同步好，但效率一般。
回写式（Write Back）：当有数据要写入数据库时，只会更新缓存，然后异步批量的将缓存数据同步到数据库上。
这种实现比较复杂，需要较多的应用逻辑，同时可能会产生数据库与缓存的不同步，但效率非常高。