精华内容
下载资源
问答
  • TiKV 底层使用了 RocksDB 作为存储引擎,然而 RocksDB 配置选项很多,很多情况下只能通过反复测试或者依靠经验来调优,甚至连 RocksDB 的开发者都自嘲,他们没办法弄清楚每个参数调整对性能的影响。如果有一个自动 ...

    作者:吴毅 王远立

    TiKV 底层使用了 RocksDB 作为存储引擎,然而 RocksDB 配置选项很多,很多情况下只能通过反复测试或者依靠经验来调优,甚至连 RocksDB 的开发者都自嘲,他们没办法弄清楚每个参数调整对性能的影响。如果有一个自动 tuning 的方案就可以大大减少调优的人力成本,同时也可能在调优的过程中,发现一些人工想不到的信息。我们从 AutoML 中得到启发,希望能用 Automated Hyper-parameter Tuning 中的一些方法来对数据库参数进行自动调优。

    常用的 Automated Hyper-parameter Tuning 方式大体上有以下三种:

    1. 随机搜索,或者说叫启发式搜索。包括 GridSearch 和 RandomSearch。这种方法的改进空间主要体现在使用不同的采样方法生成配置,但本质上仍然是随机试验不同的配置,没有根据跑出来的结果来反馈指导采样过程,效率比较低。

    2. Multi-armed Bandit。这种方法综合考虑了“探索”和“利用”两个问题,既可以配置更多资源(也就是采样机会)给搜索空间中效果更优的一部分,也会考虑尝试尽量多的可能性。Bandit 结合贝叶斯优化,就构成了传统的 AutoML 的核心。

    3. 深度强化学习。强化学习在 AutoML 中最著名的应用就是 NAS,用于自动生成神经网络结构。另外它在 深度学习参数调优 中也有应用。它的优点是从“从数据中学习”转变为“从动作中学习”(比如 knob 中的 cache size 从小调到大),既可以从性能好的样本中学习,也可以从性能坏的样本中学习。但强化学习的坑也比较多,体现在训练可能比较困难,有时结果比较难复现。

    目前学术界针对 auto-tune 数据库的研究也有很多,采用的方法大多集中在后面两种。其中一个比较有名的研究是 OtterTune我们受 OtterTune 的启发,开发了 AutoTiKV,一个用于对 TiKV 数据库进行自动调优的工具。项目启动三个月以来,AutoTiKV 在 TiKV 内部测试和调参的环节起到了较好的效果,有了一个很好的开始。后续我们还会针对生产环境上的一些特点,对它进行继续探索和完善。

    项目地址:https://github.com/tikv/auto-tikv

    设计目标

    整个调优过程大致如下图:

    图 1 调优过程

    整个过程会循环跑 200 个 round(可以用户自定义),或者也可以定义成到结果收敛为止。

    AutoTiKV 支持在修改参数之后重启 TiKV(如果不需要也可以选择不重启)。需要调节的参数和需要查看的 metric 可以在 controller.py 里声明。

    一开始的 10 轮(具体大小可以调节)是用随机生成的 knob 去 benchmark,以便收集初始数据集。之后的都是用 ML 模型推荐的参数去 benchmark。

    ML 模型

    AutoTiKV 使用了和 OtterTune 一样的高斯过程回归(Gaussian Process Regression,以下简称 GP)来推荐新的 knob[1],它是基于高斯分布的一种非参数模型。高斯过程回归的好处是:

    1. 和神经网络之类的方法相比,GP 属于无参数模型,算法计算量相对较低,而且在训练样本很少的情况下表现比 NN 更好。

    2. 它能估计样本的分布情况,即 X 的均值 m(X) 和标准差 s(X)。若 X 周围的数据不多,则它被估计出的标准差 s(X) 会偏大(表示这个样本 X 和其他数据点的差异大)。直观的理解是若数据不多,则不确定性会大,体现在标准差偏大。反之,数据足够时,不确定性减少,标准差会偏小。这个特性后面会用到。

    但 GP 本身其实只能估计样本的分布,为了得到最终的预测值,我们需要把它应用到贝叶斯优化(Bayesian Optimization)中。贝叶斯优化算法大致可分为两步:

    1. 通过 GP 估计出函数的分布情况。

    2. 通过采集函数(Acquisition Function)指导下一步的采样(也就是给出推荐值)。

    采集函数(Acquisition Function)的作用是:在寻找新的推荐值的时候,平衡探索(exploration)和利用(exploitation)两个性质:

    • exploration:在目前数据量较少的未知区域探索新的点。
    • exploitation:对于数据量足够多的已知区域,利用这些数据训练模型进行估计,找出最优值。

    在推荐的过程中,需要平衡上述两种指标。exploitation 过多会导致结果陷入局部最优值(重复推荐目前已知的最好的点,但可能还有更好的点没被发现),而 exploration 过多又会导致搜索效率太低(一直在探索新区域,而没有对当前比较好的区域进行深入尝试)。而平衡二者的核心思想是:当数据足够多时,利用现有的数据推荐;当缺少数据时,我们在点最少的区域进行探索,探索最未知的区域能给我们最大的信息量。

    贝叶斯优化的第二步就可以帮我们实现这一思想。前面提到 GP 可以帮我们估计 X 的均值 m(X) 和标准差 s(X),其中均值 m(x) 可以作为 exploitation 的表征值,而标准差 s(x) 可以作为 exploration 的表征值。这样就可以用贝叶斯优化方法来求解了。

    使用置信区间上界(Upper Confidence Bound)作为采集函数。假设我们需要找 X 使 Y 值尽可能大,则 U(X) = m(X) + k*s(X),其中 k > 0 是可调的系数。我们只要找 X 使 U(X) 尽可能大即可。

    • U(X) 大,则可能 m(X) 大,也可能 s(X) 大。

    • s(X) 大,则说明 X 周围数据不多,需要探索未知区域新的点。

    • m(X) 大,说明估计的 Y 值均值大, 则需要利用已知数据找到效果好的点。

    • 其中系数 k 影响着探索和利用的比例,k 越大,越鼓励探索新的区域。

    在具体实现中,一开始随机生成若干个 candidate knobs,然后用上述模型计算出它们的 U(X),找出 U(X) 最大的那一个作为本次推荐的结果。

    数据库参数

    workload

    测试中我们使用了 YCSB 来模拟 write heavy、long range scan、short range scan 和 point-lookup 四种典型 workload。数据库大小都是 80GB。[2]

    knobs

    我们试验了如下参数:

    OptionsExpected behaviorvalid range/value set
    write-buffer-sizepoint-lookup, range-scan: larger the better[64MB, 1GB]
    max-bytes-for-level-basepoint-lookup, range-scan: larger the better[512MB, 4GB]
    target-file-size-basepoint-lookup, range-scan: larger the better{8M, 16M, 32M, 64M, 128M}
    disable-auto-compactionswrite-heavy: turn on is better point-lookup, range-scan: turn off is better{1, 0}
    block-sizepoint-lookup: smaller the better, range-scan: larger the better{4k,8k,16k,32k,64k}
    bloom-filter-bits-per-keypoint-lookup, range-scan: larger the better[5,10,15,20]
    optimize-filters-for-hitspoint-lookup, range-scan: turn off is better{1,0}

    这些参数的含义如下:

    • block-size:RocksDB 会将数据存放在 data block 里面,block-size 设置这些 block 的大小,当需要访问某一个 key 的时候,RocksDB 需要读取这个 key 所在的整个 block。对于点查,更大的 block 会增加读放大,影响性能,但是对于范围查询,更大的 block 能够更有效的利用磁盘带宽。

    • disable-auto-compactions:定义是否关闭 compaction。compaction 会占用磁盘带宽,影响写入速度。但如果 LSM 得不到 compact, level0 文件会累积,影响读性能。其实本身 compaction 也是一个有趣的 auto-tuning 的方向

    • write-buffer-size:单个 memtable 的大小限制(最大值)。理论上说更大的 memtable 会增加二分查找插入位置的消耗,但是之前的初步试验发现这个选项对 writeheavy 影响并不明显。

    • max-bytes-for-level-base:LSM tree 里面 level1 的总大小。在数据量固定的情况下,这个值更大意味着其实 LSM 的层数更小,对读有利。

    • target-file-size-base:假设 target-file-size-multiplier=1 的情况下,这个选项设置的是每个 SST 文件的大小。这个值偏小的话意味着 SST 文件更多,会影响读性能。

    • bloom-filter-bits-per-key:设置 Bloom Filter 的位数。对于读操作这一项越大越好。

    • optimize-filters-for-hits:True 表示关闭 LSM 最底层的 bloom filter。这个选项主要是因为最底层的 bloom filter 总大小比较大,比较占用 block cache 空间。如果已知查询的 key 一定在数据库中存,最底层 bloom filter 其实是没有作用的。

    metrics

    我们选择了如下几个 metrics 作为优化指标。

    • throughput:根据具体 workload 不同又分为 write throughput、get throughput、scan throughput

    • latency:根据具体 workload 不同又分为 write latency、get latency、scan latency

    • store_size

    • compaction_cpu

    其中 throughput 和 latency 通过 go-ycsb 的输出结果获得,store_size 和 compaction_cpu 通过 tikv-ctl 获得。

    实验测试结果

    测试平台

    AMD Ryzen5-2600 (6C12T),32GB RAM,512GB NVME SSD,Ubuntu 18.04,tidb-ansible 用的 master 版本。

    所有的实验都是前 10 轮用随机生成的配置,后面使用模型推荐的配置:

    workload=writeheavy  knobs={disable-auto-compactions, block-size}  metric=write_latency
    

    实验效果如下:

    这个实验中推荐结果是启用 compaction、同时 block size 设为 4KB。

    虽然一般来说写入时需要关闭 compaction 以提升性能,但分析后发现由于 TiKV 使用了 Percolator 进行分布式事务,写流程也涉及读操作(写冲突检测),所以关闭 compaction 也导致写入性能下降。同理更小的 block size 提高点查性能,对 TiKV 的写流程性能也有提升。

    接下来用 point lookup 这一纯读取的 workload 进行了试验:

    workload=pntlookup80  knobs={'bloom-filter-bits-per-key', 'optimize-filters-for-hits', 'block-size', 'disable-auto-compactions'}  metric=get_latency
    

    实验效果如下:

    推荐结果为:bloom-filter-bits-per-key20,block-size4K,不 disable auto compaction。而 optimize-filters-for-hits 是否启用影响不大(所以会出现这一项的推荐结果一直在摇摆的情况)。

    推荐的结果都挺符合预期的。关于 optimize-filter 这一项,应该是试验里面 block cache 足够大,所以 bloom filter 大小对 cache 性能影响不大;而且我们是设置 default CF 相应的选项(关于 TiKV 中对 RocksDB CF 的使用,可以参考 《TiKV 是如何存取数据的》),而对于 TiKV 来说查询 default CF 之前我们已经确定相应的 key 肯定存在,所以是否有 filter 并没有影响。之后的试验中我们会设置 writeCF 中的 optimize-filters-for-hits(defaultCF 的这一项默认就是 0 了);然后分别设置 defaultCF 和 writeCF 中的 bloom-filter-bits-per-key,把它们作为两个 knob。

    为了能尽量测出来 bloom filter 的效果,除了上述改动之外,我们把 workload 也改了一下:把 run phase 的 recordcount 设成 load phase 的两倍大,这样强制有一半的查找对应的 key 不存在,这样应该会测出来 write CF 的 optimize-filters-for-hits 必须关闭。改完之后的 workload 如下:

    workload=pntlookup80  knobs={rocksdb.writecf.bloom-filter-bits-per-key,  rocksdb.defaultcf.bloom-filter-bits-per-key, rocksdb.writecf.optimize-filters-for-hits,  rocksdb.defaultcf.block-size, rocksdb.defaultcf.disable-auto-compactions}  metric=get_throughput
    

    这次的实验效果如下(发现一个很出乎意料的现象):

    测出来发现推荐配置基本集中在以下两种:

    • {3,1,1,0,0}

      rocksdb.writecf.bloom-filter-bits-per-key [‘rocksdb’, ‘writecf’] bloom-filter-bits-per-key 20

      rocksdb.defaultcf.bloom-filter-bits-per-key [‘rocksdb’, ‘defaultcf’] bloom-filter-bits-per-key 10

      rocksdb.writecf.optimize-filters-for-hits [‘rocksdb’, ‘writecf’] optimize-filters-for-hits True

      rocksdb.defaultcf.block-size [‘rocksdb’, ‘defaultcf’] block-size 4KB

      rocksdb.defaultcf.disable-auto-compactions [‘rocksdb’, ‘defaultcf’] disable-auto-compactions False

    • {2,2,0,0,0}

      rocksdb.writecf.bloom-filter-bits-per-key [‘rocksdb’, ‘writecf’] bloom-filter-bits-per-key 15

      rocksdb.defaultcf.bloom-filter-bits-per-key [‘rocksdb’, ‘defaultcf’] bloom-filter-bits-per-key 15

      rocksdb.writecf.optimize-filters-for-hits [‘rocksdb’, ‘writecf’] optimize-filters-for-hits False

      rocksdb.defaultcf.block-size [‘rocksdb’, ‘defaultcf’] block-size 4KB

      rocksdb.defaultcf.disable-auto-compactions [‘rocksdb’, ‘defaultcf’] disable-auto-compactions False

    分析了一下,感觉是因为 write CF 比较小,当 block cache size 足够大时,bloom filter 的效果可能就不很明显了。

    如果仔细看一下结果,比较如下两个 sample,会发现一个现象:

    • 30 , 2019-08-23 03:03:42 , [3. 1. 1. 0. 0.] , [4.30542000e+04 1.18890000e+04 8.68628124e+10 5.10200000e+01]

    • 20 , 2019-08-22 16:09:26 , [3. 1. 0. 0. 0.] , [4.24397000e+04 1.20590000e+04 8.68403016e+10 5.07300000e+01]

    它们 knob 的唯一区别就是 30 号关闭了底层 bloom filter(optimize-filters-for-hitsTrue),20 号启用了底层 bloom filter(optimize-filters-for-hitsFalse)。结果 20 号的 throughput 比 30 还低了一点,和预期完全不一样。于是我们打开 Grafana 琢磨了一下,分别截取了这两个 sample 运行时段的图表:

    (两种场景 run 时候的 block-cache-size 都是 12.8GB)

    图中粉色竖线左边是 load 阶段,右边是 run 阶段。可以看出来这两种情况下 cache hit 其实相差不大,而且 20 号还稍微低一点点。这种情况是因为 bloom filter 本身也是占空间的,如果本来 block cache size 够用,但 bloom filter 占空间又比较大,就会影响 cache hit。这个一开始确实没有预料到。其实这是一个好事情,说明 ML 模型确实可以帮我们发现一些人工想不到的东西。

    接下来再试验一下 short range scan。这次要优化的 metric 改成 scan latency:

    workload=shortscan    knobs={'bloom-filter-bits-per-key', 'optimize-filters-for-hits', 'block-size', 'disable-auto-compactions'}  metric=scan_latency
    

    实验结果如下:

    由于篇幅有限我们先看前 45 轮的结果。这个推荐结果还没有完全收敛,但基本上满足 optimize-filters-for-hitsFalse,block-size32KB 或者 64KB,disable-auto-compactions==False,这三个也是对结果影响最明显的参数了。根据 Intel 的 SSD 白皮书,SSD 对 32KB 和 64KB 大小的随机读性能其实差不多。bloom filter 的位数对 scan 操作的影响也不大。这个实验结果也是符合预期了。

    与 OtterTune 的不同点

    我们的试验场景和 OtterTune 还是有一些区别的,主要集中在以下几点[3][4]:

    • AutoTiKV 直接和 DB 运行在同一台机器上,而不是像 OtterTune 一样设置一个集中式的训练服务器。但其实这样并不会占用很多资源,还避免了不同机器配置不一样造成数据不一致的问题。

    • 省去了 workload mapping(OtterTune 加了这一步来从 repository 中挑出和当前 workload 最像的训练样本,而我们目前默认 workload 类型只有一种)。

    • 要调的 knobs 比较少,省去了 identity important knobs(OtterTune 是通过 Lasso Regression 选出 10 个最重要的 knob 进行调优)。

    • 另外我们重构了 OtterTune 的架构,减少了对具体数据库系统的耦合度。更方便将整个模型和 pipeline 移植到其他系统上(只需修改 controller.py 中具体操作数据库系统的语句即可,其它都不用修改),也更适合比起 SQL 更加轻量的 KV 数据库。

    • 最后我们解决了 OtterTune 中只能调整 global knob,无法调节不同 session 中同名 knob 的问题。

    总结

    一个复杂的系统需要很多环节的取舍和平衡,才能使得总体运行效果达到最好。这需要对整个系统各个环节都有很深入的理解。而使用机器学习算法来做参数组合探索,确实会起到很多意想不到的效果。在我们的实验过程中,AutoTiKV 推荐的配置有些就和人工预期的情况不符,进而帮助我们发现了系统的一些问题:

    • 有些参数对结果的影响并没有很大。比如这个参数起作用的场景根本没有触发,或者说和它相关的硬件并没有出现性能瓶颈。

    • 有些参数直接动态调整是达不到效果的,或者需要跑足够长时间的 workload 才能看出效果。例如 block cache size 刚从小改大的一小段时间肯定是装不满的,必须要等 workload 足够把它填满之后,才能看出大缓存对总体 cache hit 的提升效果。

    • 有些参数的效果和预期相反,分析了发现该参数其实是有副作用的,在某些场景下就不大行了(比如上面的 bloom filter 那个例子)。

    • 有些 workload 并不是完全的读或者写,还会掺杂一些别的操作。而人工判断预期效果的时候很可能忽略这一点(比如上面的 writeheavy)。特别是在实际生产环境中,DBA 并不能提前知道会遇到什么样的 workload。这大概也就是自动调优的作用吧。

    后续我们还会对 AutoTiKV 继续进行改进,方向集中在以下几点:

    • 动态适应不断变化的 workload(比如一会读一会写),以及之前没有出现过的不同业务特征的 workload。

    • 有时 ML 模型有可能陷入局部最优(尝试的 knob 组合不全,限于若干个当前效果还不错的 knob 循环推荐了)。

    • 借鉴 AutoML 中的思路,尝试更多不同的 ML 模型来提高推荐效果,减少推荐所需时间。

    参考资料

    [1] https://mp.weixin.qq.com/s/y8VIieK0LO37SjRRyPhtrw

    [2] https://github.com/brianfrankcooper/YCSB/wiki/Core-Properties

    [3] https://www.cnblogs.com/pdev/p/10948322.html

    [4] https://www.cnblogs.com/pdev/p/10903628.html

    原文阅读https://pingcap.com/blog-cn/autotikv/

    展开全文
  • 数据库调优,其中一个重点就是应用程序的SQL调优。而应用程序的调优范围比较广,可以从调整业务的角度做调优,也可以从重构代码的角度调优。但是无论用什么办法调优,都必须要先读懂SQL的执行计划,了解应用程序的...
  • 数据库调优

    2020-03-11 10:22:33
    接下来问题是如何对MySQL进行调优,怎么优化SQL以及MySQL的配置,才能发挥MySQL的性能? 一.SQL语句的优化 对SQL语句的优化主要体现在对索引的使用 书写SQL的时候要注意,某些特殊的语句是没有办法使用索引的。 ...

    前几篇我们已经完成了数据库的表设计。

    新零售平台的数据库设计(一)

    新零售平台的数据库设计(二)

    新零售平台数据库的设计(三)

    接下来问题是如何对MySQL进行调优,怎么优化SQL以及MySQL的配置,才能发挥MySQL的性能?

    一.SQL语句的优化

    对SQL语句的优化主要体现在对索引的使用
    书写SQL的时候要注意,某些特殊的语句是没有办法使用索引的。

    1. 使用模糊查询的时候,%如果写在前面,是没有办法通过索引检索的。
    2. Order By 语句如果是对索引的属性排序,速度会很快。
    3. 使用is null 或者 is not null ,MySQL查询的时候会放弃使用索引,而是使用遍历检索。可以设置一些逻辑上不可能出现的值来表示NULL
    4. 因为索引是按照大小排列的,因此不要使用!=这样的符号来进行索引,可以使用同时满足小于和大于的条件来检索。
    5. 少使用OR运算符,这样第一个OR条件可能会使用索引,但是第二个是不会使用索引检索的,可以通过UNION ALL 把两个检索条件合并。(最左分配原则)
    6. 避免运算符出现在表达式的左侧,这样同样不会使用索引检索。

    二.MySQL的参数调优

    在MySQL数据库中,我们可以通过设置参数来优化MySQL的配置,主要的形式是修改my.cnf,然后重启MySQL。

    MySQL的重要参数有以下几个:

    1. max-connections 最大连接数 。

    • 表示MySQL的最大并发连接数,默认值是151,MySQL允许的最大连接上限是16000多。
    • 实际连接数是最大连接数的85%比较合适。
    • 注意不要盲目地调大max_connections,因为每一个连接都会占用一个缓冲池。
     		- show variable like 'max_connection'    用于查看最大连接数值
    
    		- show status like 'max_used_connections'   用于查看曾经出现过的最大连接数
    

    2. back_log 请求堆栈

    • 连接数到达最大连接数之后,数据库会把多余的请求放在堆栈中,back_log的值就是指堆栈中允许的最多请求数量,默认值是50。
    • back_log为max_connections的30%比较恰当。

    3. innodb_thread_concurrency 并发线程数

    • 指MySQL允许的最大线程数量,默认值为0,表示不设上限。
    • 因为线程数变多之后,线程的调度同样要耗费大量的资源。
    • 最佳值是CPU核心的2倍。

    4. innodb_buffer_pool_size 指 InnoDB的缓存容量

    • 数据库的查询缓存是缓存select结果集,当某个数据删改之后,会造成大面积的缓存失效。
    • 与数据库的查询缓存不同,innoDB不会把查询的结果集缓存在内存上,而是缓存一部分数据以及索引,提升查询的效率。
    • 默认值为128M,最佳容量是内存的70%。

    三.查看慢查询日志

    MySQL提供了慢查询日志,帮我们记录SQL中花费时间超过规定的时间的语句。

    show variables like ‘slow_query%’

    可以查询出当前的慢查询日志是否开启,以及日志的存放目录。

    同样的在my.cnf中去修改参数

    slow_query_log = on 开启慢日志

    log_query_time =1 把规定的时间设置为1S

    然后按照之前的慢查询日志的目录,我们就可以看到执行较慢的语句的具体信息。

    可以通过explain去分析执行较慢语句的执行情况。

    展开全文
  • 说起性能调优,可以说是面试中、实际工作中经常会面对的一个系列问题,在硬件条件非常有限的情况下,如果让系统跑得通、跑得快,是考验一个程序员,特别是高级程序员很重要的专业命题。
  • {管理信息化 ORACLE}Oracle10g 数据 库性能调优办法研究 内容摘要数据库系统的性能最终了决定数据库的可用性和生命力大多数数据 库系统在运行一段时间后都会存在一定的性能问题主要涉及数据库硬件数据 库服务器...
  • mysql作为一款大众免费开源的关系型数据库软件,受到很多“穷屌丝”企业的热烈欢迎,看一下目前最新数据库排行,Mysql排在第二位,仅此于oracle,看来被甲骨文收购后,市场地位上升了很多。 Jul 2021 Jun ...

    1、为啥要死磕Mysql

    Mysql作为一款大众免费开源的关系型数据库软件,受到国内很多“穷屌丝”企业的热烈欢迎,看一下目前最新数据库排行,Mysql排在第二位,仅此于Oracle,看来被甲骨文收购后,市场地位上升了很多;既然常用,咱们完全可以精通起来,相关的其他产品都是相通的,例如PG数据库,近期也比较火。

    Jul
    2021
    Jun
    2021
    Jul
    2020
    DBMSDatabase ModelScore
    1.1.1.Oracle detailed informationRelational, Multi-model info1262.66
    2.2.2.MySQL detailed informationRelational, Multi-model info1228.38
    3.3.3.Microsoft SQL Server detailed informationRelational, Multi-model info981.95
    4.4.4.PostgreSQL detailed informationRelational, Multi-model info577.15
    5.5.5.MongoDB detailed informationDocument, Multi-model info496.16
    6.up arrow 7.up arrow 8.Redis detailed informationKey-value, Multi-model info168.31
    7.down arrow 6.down arrow 6.IBM Db2Relational, Multi-model info165.15
    8.8.down arrow 7.Elasticsearch detailed informationSearch engine, Multi-model info155.76
    9.9.9.SQLite detailed informationRelational130.20
    10.up arrow 11.10.Cassandra detailed informationWide column114.00

    既然myql在企业中这么受欢迎,当然在面试中,企业的招聘JD中会经常提及,接下来,重点从面试的角度,带大家如何从容应对面试种种苛刻的问题。

    2、面试与被面试角色的互换

    相信各位读者,这些年应该或多或少的参加了一些技术面试,在这里,先说说我自己这些年的面试经历:

     最初,作为一名初级岗位的程序猿,经常会被一些索引,ddl,dml,字段定义,SQL,函数等相关的基础知识点。但是随着这些年培训机构的兴起,刚毕业的大学生都在探讨红黑树,hash链表底层原理的内容;反观在职场工作多年的程序猿,默默的在“啃老”,没有与时俱进。

    15年左右,参加过一次面试,被提及一个开放型的问题,“使用Mysql过程中,都可以从哪些角度调优?”

    我当时夸夸其谈,重点从索引创建,如何避免索引失效,SQL书写的注意事项等方面来回答,面试自我感觉良好,其实只是一个初级偏上的程序猿;现在回首往事,如果让我再来一次,我可以做的更好;

    当然这些年,我也从事一些技术面试工作,数据库优化,JVM调优,多线程并发都是面试的热点问题。

    面试中可以造火箭,面试完,其实自己就是个螺丝钉,哈哈。。。。

    另外如果各位在这些年中,也参与过一些面试,可以看看我思考的角度是否全面,欢迎留言,互相学习,共同成长。

    以下是我这些年,面试和被面试,以及持续学习过程中,慢慢积累的心得体会,分享给大家,希望对大家有帮助,指亮迷茫中的你。

    3、如何做mysql数据库性能调优

    上面啰嗦了这么多,切入正题,咱们依旧从这个开放性的问题来谈起,带大家以一种结构化的思维来这个开放性的问题:

    3.1、从硬件角度思考

    如果不考虑成本的情况下,数据库所在的主机硬盘应该采用固态硬盘(SSD)替代机械硬盘,固态硬盘IO读取速度比机械硬盘快很多。

    故障举栗

    在主从集群部署的框架下面,主节点负责增删改操作,从节点负责查询,从节点从主节点获取数据变更数据(binlog)

    从节点所在机器采用固态硬盘,当业务高峰时,主从数据不一致的情况时有发生,例如客人下了一个订单,但是查询查不到数据。

    3.2、从数据库部署架构上,采用集群架构,读写分离的形式

    这样部署的好处大概有以下几点:

    1、采用多个副本机制,当主库不可用,可以从从库中选择一台作为主,减少数据库宕机造成的影响。

    2、主从架构可以水平扩展,提升数据库集群整体的并发响应能力。

    缺点:

    数据冗余

    3.3、从整体的应用架构出发

    数据库作为各个应用系统的最宝贵资源,一旦驾崩了,后果很难预估,所以从整体的应用架构出发,咱们可以尝试降低数据库的压力,常规的骚操作,无非是在数据库层上,架设一层缓存,缓存一些频繁检索的热点数据,常规的可以采用redis,ehcache,更夸张的可以使用jvm内存,但是笔者不建议,不方便应用的水平扩展。

    当然架设了缓存,需要防范缓存的穿透(恶意请求),缓存的雪崩等等一些问题。

    3.4、从连接数据库环节说起

    为了避免频繁的创建数据库连接,降低连接带来的IO开销,可以采用池化技术,例如老牌的c3p0,阿里的druid连接池,初始化一批连接。当应用需要连接时,直接从池中获取已经创建好的连接,当然池化技术也带来了额外问题,客户端对连接关闭处理的不好,导致连接泄露,白白占用了宝贵的连接资源。

    3.5、从数据库服务端,SQL执行流程说起(知识铺垫)

    SQL提交到服务器涉及以下几个环节:

    1、连接器:连接管理、权限验证

    2、分析器:词法分析、语义分析

    3、优化器:优化执行过程(基于成本分析、规则分析)

    4、执行器:跟存储引擎交互,Mysql5.5版本开始,采用innodb作为默认的存储引擎。

    这一块的知识点作为后续讲解SQL性能调优承上启下使用,先做个铺垫。

    3.6、数据库索引

    谈到索引,带大家从以下几个角度回顾一下对应的知识点:

    3.6.1索引的作用

    索引的作用相当于图书的目录,可以根据目录中的页码快速找到所需的内容。索引提供指向存储在表的指定列中的数据值的指针,然后根据您指定的排序顺序对这些指针排序。

    3.6.2索引的数据结构

    学习一样技能,咱们先去尝试接受他,然后再尝试扪心自问,为啥要这样设计?我们知道Mysql中索引的存储结构采用B+树,经常有以下一个面试题:

    经典面试题:为什么mysql索引用B+树而不用哈希表???

    回答上面这个问题之前,咱们 先来学习一下树相关的数据结构:

    推荐一款数据结构学习的网址:https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

    常见的有二叉查找树、AVL树、B树、B+,大家可以基于上面的网址,把玩一下各个数据结构,随意添加删除节点,观察树的变化。

    <一>二叉查找树:

    树的数据结构特征,左子节点小于父节点,右子节点大于父节点,所以二叉树有个致命的问题,容易演变成线性链表:

                                             

    链表的深度,决定了数据检索的IO次数,每个节点存储了左子树,右子树的指针,以及data,假设此时检索5,需要检索IO5次。

     <二>AVL树,平衡二叉查找树

    它是一棵空树或它的左右两个子树的高度差的绝对值不超过1,并且左右两个子树都是一棵平衡二叉树。而这里提到的高度差,就是我们下面会引入的平衡因子:BF(balance factor) 

     可以结合上面的网址,自己演示一下,当持续输入1,2,3,4,5,树的结构并非是一颗线性树,通过自身的旋转,满足平衡二叉查找树的特征。

    这时检索5,IO的次数是3,性能明显提升了。

    咱们日常大表的数据量至少能够达到百万级,如果按照平衡二叉查找树存放数据,树的深度依然很深,导致IO检索次数依旧很高,性能低下。

    此处需要分享个概念:叶的概念

    innodb是数据和索引存放在一个文件中,每个节点存放的数据单位(page),默认为16kb,按照

    假设一条记录,以及节点左右子节点的指针大小为30byte    16*1024/30   =546记录

    在这里插播一条面试点:表的列字段类型应该是定义为int ,还是varchar?

    VARCHAR(M)定义的列的长度为可变长字符串,M取值可以为0~65535之间,(VARCHAR的最大有效长度由最大行大小和使用的字符集确定。整体最大长度是65,532字节)。VARCHAR值保存时只保存需要的字符数,另加一个字节来记录长度(如果列声明的长度超过255,则使用两个字节)。VARCHAR值保存时不进行填充。当值保存和检索时尾部的空格仍保留,符合标准SQL。varchar存储变长数据,但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为 VARCHAR(10)是最合算的。
     

    引出来接下来要聊的知识点,多路平衡二叉查找树

     <三>B树  多路平衡二叉查找树

     基于多路二叉查找树的思想,如果非叶子节点只存放聚焦索引值以及左右子节点的指针,把行数据单独存储在叶子节点中,这样非叶子节点可以存放更多的索引数据。

    <四> B+树,作为B树的升级版本

    B+树遵从 左节点 < 父节点 < 右节点;最底层叶子节点严格按照从小到大顺序排列。

    这样看B+树天生是为了范围查询而设计的。

    写到这里,大家应该能知道mysql索引为啥不用hash索引,hash索引是将数据散列,针对范围检索时,只能一个个查找,显然不符合性能要求。

    3.6.3索引的分类

    索引分类:主键索引、唯一索引、普通索引、全文索引、组合索引

    1、主键索引:即主索引,根据主键pk_clolum(length)建立索引,不允许重复,不允许空值

     ALTER TABLE 'table_name' ADD PRIMARY KEY pk_index('col');

    2、唯一索引:用来建立索引的列的值必须是唯一的,允许空值

    ALTER TABLE 'table_name' ADD UNIQUE INDEX index_name('col');

    3、普通索引:用表中的普通列构建的索引,没有任何限制

    ALTER TABLE 'table_name' ADD INDEX index_name('col');

    4、全文索引:用大文本对象的列构建的索引

    ALTER TABLE 'table_name' ADD FULLTEXT INDEX ft_index('col');

     -----mysql的全文索引,其实在实际场景中大家很少使用,elasticsearch在这方面有天然的优势

    5、组合索引:用多个列组合构建的索引,这多个列中的值不允许有空值

    ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3');

    面试问题:一张表会不会没有主键索引??

    在mysql的技术文档里面有如下文字,可以回答这个问题:

    If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULL columns as the primary key and InnoDB uses it as the clustered index. If there is no such index in the table, InnoDB internally generates a clustered index where the rows are ordered by the row ID that InnoDB assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion order.

    如果没有主动设置主键,就会选一个不包含NULL的第一个唯一索引列作为主键列,并把它用作一个聚集索引。如果没有这样的索引就会使用行号生成一个聚集索引,把它当做主键,这个行号6bytes,自增。可以用select _rowid from table来查询。

    咱们在学习innodb事务的隔离级别时,我们知道建一张表,MySQL会给咱们建几个隐藏的列,其中一列就是rowid.  MVCC章节中详细来聊这一块。

    3.6.4索引的失效

    这个点,面试中经常会被问到,即使高级程序猿,也会不小心犯错,例如检索条件中,针对索引字段做隐式转换、使用函数、模糊检索‘%XXX%’,会导致全表检索。

    组合索引没有没有依照顺序列出检索条件,中间又跳过某个字段的现象,导致索引没有办法正常使用,索引覆盖知识点重点来阐述。

    1针对索引字段,模糊检索,%不能放在最左边
    2针对索引字段,不可以添加函数表达式
    3

    针对组合索引,不满足最最匹配原则(这里有个细节注意)

    temp表有A,B,C三个字段构成组合索引,

    此时select a,b,c from temp  where B=XX  and A=XX,SQL 优化引擎会将SQL执行,符合最左匹配的原则,执行。

    4针对索引字段,索引字段不能包含表达式计算
    5针对索引字段,如果取值与字段类型不匹配,也会导致索引失效

    其实上面罗列的这些,还是要深入理解索引的存储结构,理解了这一块,自然就会明白为啥不能走索引,B+数据检索的时候,需要有个明确的值匹配过程,而不是让MySQL无从查找,就比如查找 姓名为“%三” 的员工列表,遇到这种非礼的要求,mysql只能全表检索。

    面试问题,in操作是否会导致索引失效??

    例如:select    * from  temp    id  in(xx,xx,xx,xx,xx);

    in的查询可以使用到索引,但是in中枚举的数据达到一定数量后,MySQL优化引擎会认为走索引和全表扫描没有区别,会走全表扫描。这个阈值是多少,有待考证!!

    3.6.5索引的调优

    索引的调优,说白了就是在日常写SQL的过程中,需要关注3.6.4章节中会导致索引失效的注意事项

    3.6.6回表、索引覆盖、索引下推

    日常我们建表的,可能一张表不止一个索引,除了主键索引外,我们还会建个普通索引,组合索引,唯一索引,来个面试题:

    面试题:

    1、是不是索引越多越好呢?

          当然不是越多越好,首先一个列是否适合创建索引,要看离散度的取值:

          count(distinct(column_name)) : count(*)//列的重复数据越多,分子越小,离散度越小,范围检索时,SQL执行引擎,会觉得全表扫描和走索引没啥区别,干脆全表扫描吧。

           其次,要结合业务的需要,可以将频繁需要组合在一起的查询的列,建成联合索引,只要符合最左匹配的要求,依旧可以发挥索引的作用。

    2、聚集索引和非聚集索引的关系?以及非聚集索引在内存的存放形式是咋样的?

          我们支持聚集索引和行数据绑定在一起,所以可以这样区分聚集索引和非聚集索引,聚集是将索引和行数据绑定在一起,而非聚集索引的叶子节点维护了聚集索引值,可以根据叶子节点找到聚集索引,进而可以检索到对应的行数据。专业术语称之为“回表

    OK,由上面的面试题,引入正题,先来说说回表,咱们先来张图:

    索引覆盖

    先来个面试题,日常咱们在写SQL 的时候,有没有会像下面这样写么?这样写有啥不好

    select * from temp   where name ='XXX'//这样写,估计会被暴打一顿,各家互联网公司研发军规里面,明确禁止这么写法,想想有啥缺点呢?

    如果此时我们只需要检索id,那么以下两种写法有啥本质的区别?

    select id,age  from temp where name='Jason'  //name,age是一个组合索引

    select *  from temp where name='Jason'

    我们知道非聚集索引的数据存放,叶子节点存放主键的值,此时根据name检索,可以走索引,压根不用回表,省去了后续的IO操作,性能可以提升很多。

    索引下推

    索引下推,主要是mysql查询引擎自身层面上,在5.6版本做的优化

    我们继续以上面的SQL为例

    select id,name,age,sex  from   temp where name='Jason'  and age=15 //name,age是一个组合索引

    上面这条SQL,需要额外查询sex,需要回表查询,在5.6版本之前,MySQL的查询引擎是这样来执行,检索条件name='Jason'发现可以命中索引,所以忽略了age=15的这个条件.

    假设库中有两条记录的name='Jason',则在非聚集索引树上会找到两个主键id,根据两个分别回表查询。根据查询结果,再根据age=15这个条件来过滤。这样效率显然低了很多,因为多了一次回表操作。

      大家可以尝试关闭索引下推,看一下执行计划:

    set optimizer_switch='index_condition_pushdown=off';

    3.7、SQL执行计划(SQL调优工具)

     explain  SQL
                id  select_type table  type  possible_keys  key   key_len   ref   rows   Extra    

    涉及字段含义:

    id:执行顺序号,值越大,越先执行

    select_type:查询类型,普通,联合,子查询等;

        simple:简单查询

        primary:主查询

        subquery:子查询

        drived(衍生):from 列表中包含的查询

        union:联合查询,union之后的

        union:联合查询的结果查询

    table:涉及的表

    type:访问类型,即数据是怎么获取到的

        system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

        const:只需匹配一行数据,如:where primary_key=x

        ref:非唯一性索引扫描,匹配多行

        range:范围匹配,如between、in

        index:取索引列,从索引文件读取

        all:全表扫描

    possible_keys:查询字段包含的索引

    key:使用的索引

    key_len:索引中使用的字节数

    rows:找到所需的记录所需要读取的行数,这个数值只是估算值,不是特别的精确。

    extra:额外信息

        Using temporary:使用临时表保存中间结果,group by

        Using filesort:对数据使用一个外部的索引排序,而不是按照表内的索引进行排序读取。也就是说mysql无法利用索引完成的排序操作称为“文件排序”

        Using index:使用了覆盖索引(Covering Index),避免了访问表的数据行,效率高 

        Using where : 表示服务器将存储引擎返回行后再应用where过滤条件

        Impossible WHERE:不可达的查询
     

    3.8、垂直拆库、拆表

    很多同学读到这个章节可能会有些懵,数据库性能调优,咋讲到垂直拆库,拆表了呢???

    垂直拆库

    其实这块的知识点,是结合系统架构演进而来的,当一个电商网站系统,流量暴增后,需要拆分售前,售后系统,有些时候图块,简单把应用层代码拷贝一份,就可以拆分成两个系统,但是数据库还是公用一个数据库,由此带来的恶梦就此而来:

    A系统操作公共表,导致锁表,影响B系统对公共表的使用,最终影响B系统业务的流转。这个时候必须得拆库,简单点,就是把数据库拷贝一份,rename数据库名称即可。

    拆表

    3.9、水平分库、分表

    水平分库,分表,相信大家日常经常遇到,oracle里面分区表做得特别好,mysql也有分区得概念,但是貌似不咋的。

    虽然我们在表上创建了相关得索引,依照B+树得特点,确实提升了检索速度,但是当表数据上千万、上亿,即使有索引,查询起来也特别得慢。

    此时大家或许会问,压死索引得最后一根稻草是啥呢,数据量达到多少,索引效率会下降,根据博主得经验,当表数据量超过7百万得时候,就应该考虑分库、分表了。

    常见得分库分表中间件,咱们常用mycat shardingjdbc

    其实也许再过个三五年,分库、分表也许很难再接触到了,这是为啥呢?

    现在中小企业都在上云,一旦上云了之后,存储空间就不是问题了,更多得由云厂商来负责运维,包括分库,分表以及数据迁移。

    4.0、事务相关知识点

    4.0.1事务的特征

          事务的特征有四种(ACID): 原子性、一致性、隔离性、持久性;                                                原子性,一个事务中的操作序列,例如转账服务:A账户扣减,B账户增加金额,必须在一个事务中完成,要么全部成功,要么全部失败,这是一个原子原子操作,不可拆分的业务单元。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。

         隔离性,A事务和B事务,互不影响,在SQL92标准中,定义了四种事务的隔离级别,供各个数据库厂商来实现, 隔离性的问题(脏读、不可重复读、幻读)。

          持久性,在事务完成以后,该事务所对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。

          一致性,在事务开始之前和事务结束以后,数据库的完整性约束没有被破坏;事务的原子性,隔离性,持久性为一致性提供了保障。

    4.0.2事务的隔离级别

    咱们看一下SQL92标准中关于事务隔离级别的定义: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

            __Table_9-SQL-transaction_isolation_levels_and_the_three_phenomena_

             _Level__________________P1______P2_______P3________________________

            | READ UNCOMMITTED     | Possib|e Possib|e Possible                |
            |                      |       |        |                          |
            | READ COMMITTED       | Not   | Possibl| Possible                 |
                                     Possible

            | REPEATABLE READ      | Not   | Not    | Possible                 |
            |                      | Possib|e Possib|e                         |
            |                      |       |        |                          |
            | SERIALIZABLE         | Not   | Not    | Not Possible             |
            |______________________|_Possib|e_Possib|e_________________________|
            |                      |       |        |                          |
            |Note: The exclusion of|these p|enomena |or SQL-transactions ex-   |
             ecuting at isolation level SERIALIZABLE is a consequence of the
             requirement that such transactions be serializable.
                    关于p1,p2,p3的问题描述:

            The isolation level specifies the kind of phenomena that can occur
             during the execution of concurrent SQL-transactions. The following
             phenomena are possible:

             1) P1 ("Dirty read"): SQL-transaction T1 modifies a row. SQL-
                transaction T2 then reads that row before T1 performs a COMMIT.
                If T1 then performs a ROLLBACK, T2 will have read a row that was
                never committed and that may thus be considered to have never
                existed.

             2) P2 ("Non-repeatable read"): SQL-transaction T1 reads a row. SQL-
                transaction T2 then modifies or deletes that row and performs
                a COMMIT. If T1 then attempts to reread the row, it may receive
                the modified value or discover that the row has been deleted.

             3) P3 ("Phantom"): SQL-transaction T1 reads the set of rows N
                that satisfy some <search condition>. SQL-transaction T2 then
                executes SQL-statements that generate one or more rows that
                satisfy the <search condition> used by SQL-transaction T1. If
                SQL-transaction T1 then repeats the initial read with the same
                <search condition>, it obtains a different collection of rows.
      我转换成以下表格,大家应该比较熟悉了:


      从以上表格,我们可以看出  读未提交,啥问题都没有解决;读已提交阶段,存在不可重复读,幻读问题;可重复读阶段,存在幻读问题,序列化解决了所有问题,但是牺牲了并发,显然不可取。

    4.0.3MVCC

    Multi-Version Concurrent Control ,简称MVCC,在mysql 中,5.5以后的版本默认采用Innodb存储引擎,在众多的存储引擎中,只有两款支持事务,其中一款就是Innodb,Innodb的MVCC+行锁(间隙锁、临键锁)解决了幻读问题。

    借助于表得几个隐藏字段,例如事务db_trx_id,结合以下三种隔离级别,看一下MVCC是如何解决胀读、不可重复、以及幻读问题

      1、读未提交:

       2、读已提交:

       3、可重复读:

    4.0.4锁

    知识普及:

    myisam存储引擎锁的粒度是表锁,innodb存储引擎锁的粒度是行锁,本章节重点聊一下innodb存储引擎中的临键锁 Next-Key Lock+间隙锁Gap Lock

     mysql 的客户端工具,建议使用Navicat 15 for MySQL,每个查询窗口是一个数据库连接;sqlyog是所有的查询窗口公用的一个连接,所以不太好操作。

          间隙锁针对范围的事务操作,范围区间没有命中结果,例如下面的参考语句 id>1 and id<5  数据库中没有记录,在RR事务隔离级别中,为了防止幻读,采用了锁住(1,5)区间,预防在事务期间,数据插入,产生幻读的情况。

          行锁Record Lock   命中了数据库的唯一一条记录,例如 where id=5,精确匹配到了一条记录,这个我们称为行锁。

           临键锁类似间隙锁,在对范围的事务操作中,范围区间有命中记录,这时会按照下图中拆分,来锁住对应的区间,预防幻读的情况的发生。

          

    4.1、学习电子书:

       需要电子书的,可以留言

    展开全文
  • 数据库优化: A.mysql语句优化【大多数语句不能简化】 B.查询命令优化:explain命令进行查询进程是否有做索引,没有经过索引,则加上索引【加索引以后,查询并没有变快,查询是否加对索引,没加对索引,进程不走...

    数据库优化:

    A.mysql语句优化【大多数语句不能简化】

    B.查询命令优化:explain命令进行查询进程是否有做索引,没有经过索引,则加上索引【加索引以后,查询并没有变快,查询是否加对索引,没加对索引,进程不走索引,无法优化】

    C.主从备份延迟优化:查看i/o线程是否为单线程【MySQL的主从复制都是单线程的操作,主库对所有DDL和DML产生的日志写进binlog,由于binlog是顺序写,所以效率很高。Slave的IO Thread线程从主库中bin log中读取取日志。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的,不是顺序的,时间会慢很多,Slave本机上还有查询,并且Slave_SQL_Running也是单线程的,所以一个DDL卡住了,需要执行10分钟,那么所有之后的DDL会等待这个DDL执行完才会继续执行,这就导致了延时】

    优化办法:升级数据库为5.7以上,开启多线程

    D.主键重复:在slave已经有该记录,又在master上插入了同一条记录

    解决办法:在slave上用desc hcy.t1; 先看下表结构:删除重复的主建,在master上和slave上再分别确认一下。

    E.更新丢失:在master上更新一条记录,而slave上找不到,丢失了数据

    解决办法:在master上,用mysqlbinlog 分析下出错的binlog日志在干什么,在slave上,查找下更新后的那条记录,应该是不存在的。

    mysql> select * from t1 where id=2;
    Empty set (0.00 sec)

    然后再到master查看

    把丢失的数据在slave上填补,然后跳过报错即可。

    F.中继日志损坏

    解决办法:找到同步的binlog和POS点,然后重新做同步,这样就可以有新的中继日值了

    展开全文
  • 达梦数据库SQL调优

    2021-02-25 14:09:43
    SQL 调优作为数据库性能调优中的最后一个环节,对查询性能产生着直接的影响。在进 行正式的 SQL 调优前,用户首先要关注下列几点: 1.达梦数据库安装时的配置参数是否符合应用场景需求; 2.达梦数据库的 INI ...
  • Mysql数据库调优——索引 参考资料: MySQL分区:https://www.bilibili.com/video/BV1E7411q7Nx MySQL_基础+高级篇- 数据库 -sql -mysql教程_mysql视频_mysql入门_尚硅谷:...
  • 数据库性能调优

    2019-11-06 11:25:20
    数据库性能调优方案 1) 硬件调整性能 1.1、最有可能影响性能的是磁盘和网络吞吐量,解决办法扩大虚拟内存,并保证有足够可以扩充的空间把数据库服务器上的不必要服务关闭掉 1.2、把数据库服务器和主域服务器分开...
  • MySQL 数据库性能调优

    千次阅读 2019-07-07 16:56:58
    MySQL 数据库性能调优优化的范围有哪些存储、主机和操作系统方面:应用程序方面:数据库优化方面:优化维度数据库优化维度有四个:优化选择:数据库层面数据库层面问题解决思路一般应急调优的思路:常规调优思路:系统...
  • HBase数据库性能调优

    2011-07-07 20:49:16
     既然split和compaction如此影响性能,有没有办法去掉?  compaction是无法避免的,split倒是可以从自动调整为手动。  只要通过将这个参数值调大到某个很难达到的值,比如100G,就可以间接禁用自动split...
  • 数据库设计: 数据库三大范式3. SQL优化定位操作4. 慢查询二、索引三、SQL语句优化技巧1 . SQL优化技巧2 . MySQL数据引擎 myisam / innodb/ memory3 . 数据库数据备份四、分库分表垂直拆分水平拆分 一、存储过程 ...
  • 有关like“%aa” 语句不调用单独的索引解决办法 1.利用select主键索引 2.覆盖索引  五。创建一个好的表 1.满足列具有原子性 2.表中记录唯一 ,有主键。3.数据能算出来,尽量算出来,不要数据冗余。...
  • 1. 数据库调优1.1.修改数据库参数以sys用户登录,运行如下的命令:alter system set optimizer_index_cost_adj=10 scope=spfilealter system set optimizer_dynamic_sampling=5 scope=spfil
  • 数据库性能优化详解

    万次阅读 多人点赞 2017-02-03 17:38:06
    1.数据库访问优化法则 要正确的优化SQL,我们需要快速定位能性的瓶颈点,也就是说快速找到我们SQL主要的开销在哪里?而大多数情况性能最慢的设备会是瓶颈点,如下载时网络速度可能会是瓶颈点,本地复制
  • 常用Oracle数据库调优工具介绍[转]

    千次阅读 2009-12-10 13:37:00
    1. 数据库调优1.1.修改数据库参数以sys用户登录,运行如下的命令:alter system set optimizer_index_cost_adj=10 scope=spfilealter system set optimizer_dynamic_sampling=5 scope=spfile optimizer_index_...
  • 以下的环境具备一定的代表性,可以说是...希望通过本文能让大家理解Linux下MySQL数据库性能调优方法。51CTO向您推荐《MySQL数据库入门与精通教程》。 硬件准备环境: 硬盘: 16块 SAS 15K RAID5 带512MCache CPU:
  • 数据库性能优化经验总结

    千次阅读 2018-08-20 13:18:58
    1.数据库访问优化法则   要正确的优化SQL,我们需要快速定位能性的瓶颈点,也就是说快速找到我们SQL主要的开销在哪里?而大多数情况性能最慢的设备会是瓶颈点,如下载时网络速度可能会是瓶颈点,本地复制文件时...
  • Oracle数据库性能调优

    2015-05-13 20:31:55
     要评价数据库的性能,需要在数据库调节前后比较其评价指标即响应时间和吞吐量之间的权衡、数据库的可用性、数据库的命中率以及内存的使用效率,以此来衡量调节措施的效果和指导调整的方向。 三、注意事项:  ...
  • Sybase数据库性能调优

    2012-04-25 13:59:00
    1 概述 ...对Sybase数据库性能调优,可以从四个方面进行: 一) 操作系统级:对网络性能、操作系统参数、硬件性能等作改进。 二) DB Server级:调整存取方法,改善内存管理和锁管理等。 三) 数据...
  • kettle的调优

    2020-07-05 09:30:13
    三、调优 1、调整JVM大小进行性能优化,修改Kettle根目录下的Spoon脚本 参数参考: -Xmx1024m:设置JVM最大可用内存为1024M -Xms512m:设置JVM促使内存为512m。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM...
  • MySQL性能调优办法

    2019-09-26 17:48:01
    1.数据库的设计 尽量把数据库设计的更小的占磁盘空间. 1).尽可能使用更小的整数类型.(mediumint就比int更合适). 2).尽可能的定义字段为not null,除非这个字段需要null. 3).如果没有用到变长字段的话比如varchar,那就...
  • MySQL数据库访问性能优化

    万次阅读 多人点赞 2018-03-01 09:07:50
    MYSQL应该是最流行的WEB后端数据库。大量应用于PHP,Ruby,Python,Java 等Web语言开发项目中,无论NOSQL发展多么快,都不影响大部分架构师选择MYSQL作为数据存储。 MYSQL如此方便和稳定,以至于我们在开发 WEB 程序...
  • 对单表超过300w+数据的Web应用程序进行测试后发现了一些功能、性能问题,采取了以下办法来进行调整

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 22,474
精华内容 8,989
关键字:

数据库调优的办法