库表设计原则 在互联网应用中，数据库访问频率很高，CPU、内存、IO、网络都是紧缺资源，因此在满足业务的前提下，降低SQL尤其是高频SQL的资源消耗就是个非常重要的优化原则了，在设计表结构时，应该考虑哪些是高频执行的SQL从而采取针对性措施。
1：单表字段数应控制在20个以内。一个表的字段越多，面临的业务场景就会越复杂，面临可能的变化也越多。当查询时，也会因为需要过滤的字段过多，导致更多的IO消耗。这个原则也可以用另外用另外一种形式表达：拆分表中字段来分离冷热数据。大字段和访问频率低的字段都会降低查询的效率，分离冷热数据后，能提示热数据的访问性能，降低IO消耗，提高缓存命中概率。
2：控制表的数据量。当数据量超过千万级别后，即使硬件性能强大，sql执行时间也会下降。
3：选择字段类型时，在满足正确存储业务数据要求的前提下，选择最短的。越小的字段，访问效率越高。不要使用TEXT、BLOB类型；不得不使用TEXT、BLOB类型时，拆分到单独表中；用DECIMAL代替FLOAT和DOUBLE存储精确浮点数；使用整数替代浮点数：比如用分为单位表示以元为单位的金额；使用数字或ENUM代替字符或字符串。
4：如果可能的话所有字段均定义为not null，因为null值使索引失效。对于数据量比较大的表而言，索引失效时查询将是灾难性的低效。

索引设计使用原则： 索引对于性能来说非常关键，尤其是数据量非常越大时。查询时使用到索引可以减少查询时扫描的数据量、避免排序、将随机IO转为顺序IO。代价就是修改或删除数据时，索引需要重新排序，降低了性能。索引还能使查询条件命中的索引作为行锁的条件
1：将索引建立在高区分度字段上。索引是按照字段内容排序的，如果字段值区分度不高，在索引中将有很多大段的相同值，用这样的索引查询时，过滤效果非常不明显，所以不要在区分度低的字段上创建索引。字段值区分度高时可以根据查询值迅速定位查询结果，提示查询效率。
2：索引应该建立在短字段上。尽量不要建在长字符串上，如果不可避免，可以选择字符串的开头几位。建立索引时要把字段内容保存到索引中，所以字段越长，索引占得硬盘空间也就越大，查询时消耗的硬盘IO资源也就越大，耗时越长。
3：创建复合索引时索引的列顺序至关重要。查询有多个条件时，适合使用复合索引查询。如果有多种查询组合条件，复合索引建立得当的话，复合索引可以复用。建立复合索引时，自个字段的顺序仍然优先按照区分度，其次再考虑索引复用。
4：不要在索引列上进行数学运算、函数运算（会使索引失效）。
5：单张表中索引数量不超过5个，单个索引中的字段数不超过5个，通常将选择性最高的列放在最前面。如果一个表的索引太多，最可能的原因是开始时这个表担负了太多的职责，考虑将此表的职责拆分。

SQL使用原则：
1：拒绝大sql，尽可能不做表之间的join操作。原因： a、MySQL更擅长简单查询，尤其是单表主键或二级索引查询；mysql一条sql只能使用一个cpu，有大表join的情况下，性能下降明显； b、大sql不仅慢，而且会大幅度降低数据库的并发能力，甚至拖垮数据库； c、使用多条简单sql，使缓存命中率更高，还可以使用多核； d、高并发场景下，不要使用两个或以上的表join。
2：限制返回结果条数，否则返回满足条件的所有记录。大多数情况下这是不必要的，应用在处理返回的大量结果时可能崩溃。
3：不要使用select *，只查询需要的列 a、select * 消耗了更多的cpu，内存，io，网络资源； b、使用具体字段除了减少资源消耗，还减小了表增加字段时的影响；
4：避免关联子查询。mysql的关联子查询实现非常糟糕，除非有非常高深的优化功力，否则不要写关联子查询。
5：避免负向查询，不要使用NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、 NOT LIKE等。不能使用索引，导致全表扫描，效率低下。
6：避免使用count。除非是非常小的表，否则尽可能使用冗余字段计数或其他方式。
7：分页时避免传统的limit offset, size方式分页。这种方式随着偏移量大，性能越来越差，可以考虑把分页转换成条件查询。
8：使用in代替or，in的值不超过200个。IN的效率（O(log n)）比OR的效率(O(n))高很多。
9：使用预编译的sql。使用预编译的sql不仅能防sql注入攻击，还可以避免mysql服务器编译的开销。