4个大的方向：分库 、 读写分离 、 设计好索引 、 优化你的查询Sql

13太保：

1，单库表别太多，一般保持在200以下

2，尽量避免SQL中出现运算，例如select a*2 from A where 3*bb = ddd

3，表设计尽量小而精，能用5个字段就不要用6个（取决于业务，该冗余时坚决不要手软）

4，SQL事务不能设计太大，比如一次性提交10W条insert，当然这个不仅仅是性能问题了，可能直接内存溢出了

一般来说insert事务的话，500-1000来做批处理就可以了（字段不能太大）

5，设计表的时候尽量用"小数据类型"，比如尽量避免text，blob等这些大家伙

6，设计表字段能用数字类型就千万别用字符类型，比如存IP地址，用int，别用varchar

7，尽量避免null字段，定义时尽量使用 not null.原因是允许null时不方便查询优化，复合索引也会失效，而且如果列有索引时会额外占用空间： a int(10) NOT NULL DEFAULT 0

8，图片等大家伙不要存DB，用fastdfs等中间件或者直接使用七牛等云存储都可以搞，也不贵

9, or尽量不用，改为in(),当然in的范围太多也不行，尽量别超100

如果：select a from A where b=1 or c=1这种where里面不同字段进行or，这种尽量改为union。 select a from A where b=1 union select a from A where c=1

10, update时，where语句尽量要走索引，不然会全表扫描，一般情况下，1G的数据至少10秒（想想这可是update啊，锁住10S意味着啥）

11, 大SQL尽量拆分，多核CPU每个CPU只能执行一个SQL，所以并发时，一堆小的可能效率更高一些，并且容易命中缓存，而且不容易长时间锁表（无论什么锁都是时间越短越好），当然这个要结合实际情况分析了，一大堆小的万一增加IO负担呢。

12, 避免 “% 前缀”模糊查询 。因为会导致索引失效，大数据量下是灾难

13, 分页时：Select a from A limit 10000,10; 这种大偏移量下效率非常低

可以考虑如下 select a from A WHERE id>=xxxx limit 11;