数据库瓶颈问题的解决思路

时　间:2018-01-26 08:54:55
作　者:缪炜   ID：24010  城市：江阴
摘　要:在数据量大的事情，往往是数据库最先体现出来瓶颈，这个时候大家往往想到缓存，缓存并不是解决问题的灵丹妙药，甚至会掩盖数据库设计不合理的问题，埋下隐患，在使用缓存之前，应先将数据库本身作用发挥到最大
正　文:

在数据量大的事情，往往是数据库最先体现出来瓶颈，这个时候大家往往想到缓存，缓存并不是解决问题的灵丹妙药，甚至会掩盖数据库设计不合理的问题，埋下隐患，在使用缓存之前，应先将数据库本身作用发挥到最大；

1、单表查询慢

    条件字段类型合理，建立适合的索引；

    如果数据量一定程度，索引也解决不了问题，比如翻页，这种情况下需要结合业务的需要，决定是进行分表还是增加缓存，并在sql上限制这些消耗过大的查询；

2、联表查询慢

2.1、第一种情况，需要呈现关联表的数据但这些数据不做为查询条件。在首次查询语句中不联表查询这些仅需要呈现的字段，而是先通过查询缩小范围，然后用另外一条语句查询需要的内容，在两张表中数据都比较大的情况下，这个方法在实际应用中的效果十分明显；

    主表table1

    从表table2

    Select t1.*,t2.t2_name from table1 t1

Left join table2 t1 on t1.t2_id = t2.t2_id

调整方法

    Select * from table1

Select * from table2 where t2_id in (1,2,3)

在通过程序关联；

2.2、第二种情况，关联表的数据而且作为查询条件。最好的办法将该字段冗余，并根据实际场景确定是否需要维护以及维护方法；

    主表table1

    从表table2

    Select t1.*,t2.t2_name from table1 t1

Left join table2 t1 on t1.t2_id = t2.t2_id

Where t2.t2_level = 1

调整方法

    主表table1

    从表table2

    这里的t2_level需要维护，因为t2_level的变化不可预知，所以在table2的行信息发生变化的时候，就需要去维护，这个时候有些人想到可以不可以用触发器，我的观点是不可以，因为数据库只会是复杂业务的一部分，如果过分依赖数据库，程序中的逻辑就可能不完整，将来在数据量进一步扩大的情况，业务的逻辑将很难扩展，所以数据库我们只拿他作为存储和检索；

3、前两条都做了，还是慢，那就是整体架构的问题了，以后再讲。

    总之，在数据库量不大的情况，想怎么玩都可以，一但数量大了，你就要思考业务和数据库的紧密结合了，这就需要设计，并在设计的过程中不断提炼和优化，没有一个完美的思路可以很好的解决这个问题，尤其在需求敏捷的状态下，更能体现一个人的责任心和能力；