• SQL查询优化——数据结构设计


    本文部分内容会涉及mysql,可能在其它数据库中并不适用。

    本章节仅仅针对数据库结构设计做讨论。查询优化的其它内容待续。

    数据库设计及使用是WEB开发程序猿必备的一项基础技能,在大数据量和高并发场景,合理的数据结构及SQL查询优化对项目来说都会显得格外重要。大部分有经验的程序猿都能了解到,程序的瓶颈往往不在程序本身,而在数据訪问层。造成数据訪问效率低下的原因有非常多,怎样解决这些问题。直接影响到应用的稳定性、健壮性。下面列举几个常见的问题:

    • 数据库锁表,查询堵塞
    • 高并发场景下。链接数量瓶颈
    • 查询效率低下。程序长时间无法退出
    • 写入性能低下。造成读写竞争激烈

    以上仅仅是列出了数据库使用过程中比較常见的问题。出现这些问题的常见原因列举例如以下:

    • 数据结构设计不合理
    • 索引设计糟糕
    • 程序维护数据链接不合理
    • 程序猿太懒惰。数据库做了不擅长的工作
    • 数据冗余
    • SQL太渣

    本节仅仅对数据结构设计不合理进行讨论。兴许章节会继续讨论其它内容。

    一直认为作为一个中级以上水平的程序猿,查询优化是一项必备的基础技能。良好的数据结构设计,直接影响到后期软件的性能、健壮性、可维护性、可扩展性。见过非常多由于数据结构设计不合理而造成软件终于难以扩展。难以维护的场景。要避免这些问题。我们就要掌握良好的数据结构设计能力。

    如何的数据结构才是合理的?这并没有一个完美通用的解决方式,要考虑详细的应用场景。但有一些准则,使我们应该尝试去遵守的。列举例如以下:

    1. 依据业务查询场景,考虑数据结构分布
    2. 假设没有业务主键,应建立ID自增主键
    3. 保证使用较小的数据类型。避免空间浪费
    4. 合理控制表的字段数量,必要时分表存储
    5. 加入字段凝视

    针对以上几点,分别详述例如以下:

    1、依据业务场景,考虑数据结构分布

    业务场景,决定了你要存储什么样的数据,但它不会决定你要怎样存储这些数据。你能够简单的将这些信息存储到一张表里,比如user表。但当我们须要很多其它的信息。比如用户的附属属性(学校,住址等),假设所有塞到一张表里,对于小数据量的数据库不会有太大问题,但当遇到大数据量的场景时,查询就有可能变的缓慢。

    分表会是一个更好的解决方式,依据不同的业务场景,将这些信息分为两类。存储在不同的表里。是更加合理的解决方式。

    这里要说的事实上是。不要为了方便把全部的东西都塞到一张表里。尽管这样会让你的程序编写起来easy非常多,可是会造成很多其它的问题。

    比如有些人会把1:N的关系存储到一张表里,这样就会带来数据冗余,坏处有非常多。比如:针对N的写改删查都会变得非常复杂;表体积变大、字段增多,造成查询缓慢;其它表链表查询时速度缓慢等等。

    2、假设没有业务主键,应建立ID自增主键

    主键是一条记录的唯一标志,没有主键在非常多时候我们无法得心应手的操作数据。可能在某些场景下。我们确实没有设置主键的必要,但不管你是否主动设置主键。数据库都会有一个主键(假设你没有主动设置。数据库默认会有一个ROW_ID列,而这一列是你看不到的)。主键在连表、查询等方面业务提供非常大帮助,所以不管怎样,建立一个主键是非常必要的

    3、保证较小的数据类型,避免空间浪费

    较小的数据类型意味着较小的存储代价,且数据库可以更高效的利用缓存空间。存储引擎都会採用不同的方式对索引或者数据缓存在内容中。较小的数据类型意味着在有限的内容空间中,你可以存储很多其它有价值的数据。

    对于可变长度的varchar类型。假设我们设置的是20长度。但实际占用的仅仅有10个长度。在加载内存时。占用的空间依然是20而不是10。所以对于可变长度类型,合理的长度更为重要。

    4、合理控制表的字段数量。必要时分表存储

    字段数量过多假设不是由于业务需且数据结构设计合理,大多会产生下面几个问题:

    • 数据冗余
    • 索引过多
    • 表体积大

    这里要提醒避免不必要的数据冗余,针对数据冗余的讨论我们暂且放在后面。

    由于字段数据量多,往往查询场景也会很复杂多变,所以索引也就跟着变多了。索引多会直接影响到表的写入性能。这个性能的损耗是很大的。可能是数以十倍计算的时间损耗。在写入频繁的场景。有可能会出现写入瓶颈。由于写入而影响读取性能的问题或许多。

    表体积大意味着数据库在读取数据的时候须要扫描很多其它更大的数据块,加载内存做缓存时也不能充分利用缓存带来的效果。表大小对于表的性能也是由为重要的。

    分表是解决字段过多的一个解决方式。数据库分表后,程序可能会修改比較大,但我们应该追求合理完美的软件设计,摒弃糟粕。分表后使用链表查询,或者在程序中做两次查询。有些人可能会认为连表。性能一定非常差,事实上不然。连表意味着我们在同一个SQL中。能够使用两个索引,可是单表查询我们仅仅能使用一个索引。

    假设索引设计合理,在大多数场景下(应该是大数据量场景)。连表查询会比单表查询性能更高,甚至高出太多。以前有过这种场景,优化分表后画面变得没好多了。

    5、加入字段凝视

    这里仅仅是为了提示规范化数据库设计。

     

    原创文章,转载请注明: 转载自始终不够

    本文链接地址: SQL查询优化——数据结构设计

    版权声明:本文博主原创文章,博客,未经同意不得转载。

  • 相关阅读:
    kali BEEF-XSS启动报错解决
    kali msfconsole启动报错解决
    unittest详解(三) 简单元素定位
    unittest详解(二) 断言
    unittest详解(一) unittest框架
    selenuim python环境安装
    Locust 脚本练习
    Locust 参数化
    Locust 设置断言
    9-04嵌套事务及事务分类
  • 原文地址:https://www.cnblogs.com/zfyouxi/p/4885000.html
Copyright © 2020-2023  润新知