标签：str 用户需求 缓存机制 常量 互联网 建表 bsp 容灾 重要
数据库的优化程度影响了一个程序的执行力和用户的体验感，所以数据库的优化显得格外重要。
一、框架
根据业务需求选择合适的开发框架，不近对数据库的优化有帮助，而且对于程序后期的维护也很有帮助，根据项目的需求，看项目需要满足多少人的访问量，并发量到多少。不是说小公司就不需要分布式、大数据这些，考虑长期的问题。
将一些固定不常变化的值，设置为常量；采用缓存机制，减少对于数据库的访问（连接池）；服务器的优化（队列）；
二、数据库本身
1.表结构的设计
表的设计来源于需求，同时表的建立也会影响需求的实现，一般建表采用第三范式（确保每列都和主键列直接相关,而不是间接相关）,但是也是根据需求进行选择。
【解释：第三范式】
比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。
【例子：登录表】
一般项目都会有登录功能，而且也是比较经常访问的，我见过的大部分的系统，表的设计是将用户登录的密码放在用户个人信息表中，一个用户信息表可能会有二三十个字段，甚至包含手机号、邮箱等一些比较隐私的信息。像这种也是能实现需求的，不过以后用户多的时候，达到百万千万级时，一条记录这么多字段，这么多的用户那一个表的数据也是蛮大的，仅仅是实现登录功能，就可能会查询好久，可能有人会说，这不怕，可以分库分表啊，将一半的数据分到令一个数据表甚至数据库中，这确实是个办法，不过其实登录也就仅仅是用户名和密码、验证码，何必搞那么多呢，而且将用户名密码和个人私人信息放在一起也不安全，万一哪天被盗，那就把个人信息透露完了，如果只把用户名、密码、验证码只与登录有关的放在一个表，那可能自动就会少一些，个人信息泄露的风险也会降低一点。
2.字段的设计
还是拿用户表来说，用户头像也是比较常见的吧，可能有的是直接把头像放入数据库中，图像占的空间也是比较大的，可能所有的个人信息还没一个头像占的空间大，这也导致了数据库容量的增大，其实将头像专门放到一个文件服务器，数据库中只保存一个url也是一种对数据库的优化。
三、数据库架构方面
上面对数据库的优化是从单个数据库来说的，也是可以满足一定的用户需求的，如果用户量比较大，访问比较多，数据量也比较大，我们可以对数据库架构进行优化，比如读写分离、分库分表。
1.读写分离
我们都知道二八原则，其实在互联网中也能体现二八原则，用户操作中大部分是浏览，读的操作，一小部分是写的操作，所以读比较频繁，写就相对不频繁，可以将数据库设计成一主多从或多主多从，这样就能减少对一个数据库服务器的压力，同样有利有弊，数据库增多也会带来一些新的问题，比如数据同步的问题，数据库节点变化的问题，增加一个数据库或减少一个数据库可能就会导致一部分用户映射不到。
2.分库分表
分库分表也是分而治之的思想，一个表或一个库的数据比较大，那就放在多个表多个库中，比如一个1000万数据库的表的查询肯定是没有两个500万数据库的表查询快，同样也是有利有弊，可能在系统设计阶段进行分库分表还好分一点，但对数据库或表的水平扩展那就麻烦了，比如增加一个数据库或表，那怎么将原来用户的数据映射到正确的数据库或表中呢。这是均分数据，还有一种分库分表是按时间或者按其他因素来分，比如新闻类的，时效性比较强，用户可能关注的也就一周的信息，那可以将比较热点的访问频率比较高的多放几个数据库，或者用SSD来存储，这样也会快一点。抢购也是，热门的可以专门搞一个数据库或多部署几个数据库，这样也能防止访问量过高导致整个项目崩溃。
3.容灾防灾
容灾防灾也是对数据库的优化，主要是对数据冗余，可能常见的就是日志、备份，定时定期做备份，防止数据丢失，通过日志也可以防止数据库异常，防止数据丢失。我们可以将数据和日志分开，放在不同的磁盘上，这样也是一种方法来进行数据库优化。还有一种备份是主从备份，这种有热备份和冷备份，我们可能听过异地多活，其实这种我们可以把对数据库的操作增加消息，让多个地方来接收消息，这样就可以实现数据同步，达到异地多活的目的。
四、硬件方面
硬件方面也有很多，比如网络带宽、服务器内存、操作系统、CPU还有上面说的SSD固态硬盘等。
标签：str 用户需求 缓存机制 常量 互联网 建表 bsp 容灾 重要
原文地址：http://www.cnblogs.com/blog-zy/p/7542349.html
