1，单库表别太多，通常保持在200如下为宜mysql
2，尽可能避免SQL中出现运算，例如select a+6 from t，让DB功能单一化redis
3，表设计尽可能小而精，能用5个字段就不要用6个（不绝对，取决于业务，该冗余时坚定不要手软）sql
4，SQL事务不能设计太大，好比一次性提交10W条insert，固然这个不只仅是性能问题了，可能直接内存溢出了缓存
通常来讲insert事务的话，5K-1W来作批处理就能够了（字段不能太大）并发
5，设计表的时候尽可能用”小数据类型”，好比尽可能避免text，blob等这些你们伙，优先使用ENUM和SET（小而美，范围有限，百益无一害）nosql
6，设计表字段能用数字类型就千万别用字符类型，好比存IP地址，用int，别用varchar（博客有参考）memcached
7，尽可能避免null字段，定义时尽可能使用 not null。缘由是容许null时不方便查询优化，复合索引也会失效，并且若是列有索引时会额外占用空间： a int(10) NOT NULL DEFAULT 0性能
8，图片等你们伙不要存DB。大数据
A，大SQL尽可能拆分，多核CPU每一个CPU只能执行一个SQL，因此并发时，一堆小的可能效率更高一些，而且容易命中缓存，并且不容易长时间锁表（不管什么锁都是时间越短越好），固然这个要结合实际状况分析了，一大堆小的万一增长IO负担呢。优化
B，事务尽量的小，代码别偷懒，全加到一个transaction中，道理很少说了
C，存储过程，触发器之类的能避就全避免了吧，维护不方便，人员变更时，不少时候就忘了，时间一长全是定时炸弹
D，禁止select *，不用问为啥了，禁止就是禁止！须要啥就取啥是王道
E，update时，where语句尽可能要走索引，否则会全表扫描，通常状况下，1G的数据至少10S（想一想这但是update啊，锁住10S意味着啥）
F，or尽可能不用，改成in()，固然in的范围太多也不行，尽可能别超100
G，仍是or，若是：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
H，避免 “% 前缀”模糊查询 。由于会致使索引失效，大数据量下是灾难
I，分页时：Select a from A limit 10000,10; 这种大偏移量下效率很是低。能够考虑以下几个方案：
select a from A WHERE id>=xxxx limit 11;(将上一页的最大值经过where id> 进行预处理，而后分页)
select a from A WHERE id >= ( select a from A limit 10000,1 ) limit 10;
select a from A inner join (select a from A limit 10000,10) using (id) ;
J，避免使用count(*)，不知道为何mysql优化这么个东西有那么难么，可是实际上大数量下这个东西真心慢，1000W以上至少几秒，做为替代方案，考虑使用nosql例如redis，memcached存下来，可是要定时校对。还有一个办法，直接作一个表存下来，每次增长或者减小都在这个表作update增减
K，UNION ALL 而非 UNION ，看须要啦，通常不用去重的业务的话去重压力不小，能省则省
L，尽可能不用 INSERT SELECT，数据量大有延迟，同步完了可能有错误