直接说结论YashanDB用得好不好很多时候真不是硬件的问题是配置的问题。我见过不少项目机器配置堆得很高但跑起来就是卡排查到最后发现是内存没分配好、并行度乱开、提交策略全默认。反过来有的项目硬件一般但调优做到位了性能直接翻倍。这篇就把我在实际项目中用YashanDB总结出来的10个配置策略掰开揉碎讲清楚每个都会说原理、给参数、讲适用场景最后还有避坑经验照着抄就行。1. 调优前必须想清楚的三件事1.1 先搞清楚你的负载类型很多人一上来就查参数、改配置这其实顺序反了。调优的第一步不是动参数而是搞清楚你的系统到底在忙什么。YashanDB和大多数数据库一样负载大致可以分为两类OLTP在线事务处理和OLAP在线分析处理。OLTP的特点是短平快事务多、单条SQL快、并发高核心痛点是延迟和并发冲突OLAP的特点是复杂查询多、扫描数据量大、跑得久核心痛点是吞吐和资源利用率。这两类负载对配置的需求完全相反OLTP需要更大的日志缓冲、更激进的事务提交策略、适度并行度OLAP则需要更大的排序区、哈希区、扫描缓冲区以及更高的并行度。你如果拿OLAP的配置去跑OLTP业务最直接的结果就是小事务慢得让人抓狂。我的习惯是拿到一个库先不做任何调整跑一周的负载采集AWR报告看TOP事件到底卡在什么地方。绝大部分情况下问题不在某个单一参数而是配置组合与负载类型不匹配。1.2 确认硬件资源的天花板配置不是越高越好所有参数都有物理边界。你得先确认机器到底有多少CPU核数、多少内存、什么样的存储。对于内存还要注意一个关键点数据库能用的内存不是你机器总内存要留出操作系统本身运行的余量。我一般建议数据库的内存规划占物理内存的50%到70%具体比例取决于这台机器是否还跑别的服务。CPU方面要看的是物理核数不是逻辑核数超线程带来的逻辑核在数据库高并发场景下不总能带来线性收益。存储这块最容易被忽略。不少人默认配了最大I/O能力但实际上你的磁盘根本扛不住。调优前最好用工具测一测随机的读写延迟和顺序读带宽心里有个底后面配I/O相关参数时才不会拍脑袋。1.3 建立性能基线再动手这是我最想强调的一点调优之前先记录下当前所有的关键性能指标。包括但不限于TPS、QPS、平均延迟、P99延迟、缓存命中率、磁盘I/O等待、活跃会话数等。没有基线的调优等于闭着眼睛开车。你改了一个参数性能确实提升了但你不知道提升到底来自这个参数还是其他因素更糟糕的是同时改了好几个参数出问题了都不知是谁的锅。我个人的习惯是用压测工具先跑20分钟标准负载记录所有指标然后每次只改一个参数再跑同样的负载对比前后差异。调优是科学实验不是玄学。2. 十个配置策略的底层逻辑2.1 第一个策略内存参数要按业务数据量配而不是按机器大小配很多人配YashanDB是这样做的机器有256G内存就把数据缓冲区设成192G觉得这就叫充分利用。这个做法在一半场景下是错的。数据缓冲区的核心作用是缓存热点数据块减少物理I/O。它的最优大小取决于两个因素活跃数据总量和访问的局部性。如果你的业务活跃数据就30G你给它190G的缓冲区多余的部分对性能没有额外帮助反而会占用其他模块如排序区、哈希区可用的内存反过来活跃数据有200G你只给它64G那命中率肯定上不去物理读自然多。我的习惯是先看数据量再看访问分布。如果查询基本都命中一个2G的热点表那给64G和192G的效果几乎一样。判断标准就是看缓冲区命中率YashanDB的动态视图里可以查到。低于95%说明缓冲不够或者访问太分散接近100%也未必是好事至少说明你给的内存超过了实际需求可以把内存省给其他部分。另外一个常见的反模式是把所有内存都给数据缓冲区忽略排序区、哈希区、日志缓冲区等。数据库的各个内存组件是要协同工作的某一块特别大不代表性能就好反而可能导致其他模块频繁溢出到磁盘造成严重的性能抖动。注意内存参数修改后通常需要重启数据库才能生效。在YashanDB中部分内存参数支持动态调整但扩展到更大值往往需要预留足够内存。生产环境修改前一定先评估重启窗口。2.2 第二个策略日志和提交策略决定事务延迟的上限事务提交是OLTP场景最频繁发生的操作也是延迟最敏感的操作。YashanDB的日志提交策略直接决定了每次事务提交的磁盘同步次数和等待时长。这个策略的核心参数控制着日志写入的刷盘方式。简单来说有两种极端模式一种是最保险的模式每次提交都把日志稳稳刷到磁盘上再返回成功数据绝对不会丢但延迟通常是最高的另一种是收益最快的模式日志先在内存里存够一定量再批量刷到磁盘事务提交延迟很低但如果出现宕机最近一小段已提交事务的数据可能会丢失。大部分OLTP系统不必选极端模式。更推荐的是折中方案事务提交时通知日志写进程开始刷盘但不等确认结果就返回成功。这种方式能把延迟压下来同时把丢失窗口压缩到极小。如果你的业务确实无法容忍任何丢失再考虑最保险的模式。我调过的一个某交易系统原来用的全同步模式平均提交延迟在8毫秒左右TPS大概三千多。改成折中方案后延迟降到1.5毫秒TPS直接翻倍还多。业务方几乎没有任何感知因为他们的系统设计本身已经考虑了重复提交的幂等性。另一个值得配的参数是日志缓冲的大小。在写入高峰期如果日志缓冲太小写日志的线程会频繁等待造成提交阻塞。一般建议至少配置到几MB级别如果单事务产生日志较多可以配到十几MB甚至更高。这个参数不用太大太大不仅浪费内存对性能也没什么额外好处。2.3 第三个策略并行度不是核数越多越快在YashanDB里并行查询的默认并行度往往并不理想。很多人直接把它设成跟CPU核数一样觉得这样能充分利用硬件。但实际测试下来并行度过高反而会让性能跳水。原因是并行查询需要把数据分片每个分片由一个并行服务进程处理最后还要汇总结果。分片和汇总的过程都有开销。在OLTP负载下事务本身就很轻量强行并行不仅没有收益反而增加了进程调度的开销和资源争抢。在OLAP负载下并行度也不是越高越好超过某个阈值后I/O和内存带宽会成为瓶颈再往上加核数只是空转。我的经验值是OLTP业务建议把并行度控制在4到8之间OLAP场景可以尝试按CPU核数的一半起配然后逐步加压测试到性能平台期为止。判断依据就是看并行服务的等待事件占比如果发现大量的并行空闲说明并行度开高了。另外日志写入、备份恢复这些后台任务也都有自己的并行度参数可以单独配置。不要为了查询性能把备份并行度也调得很高否则业务高峰期备份任务会把I/O带宽吃掉造成业务查询性能抖动。2.4 第四个策略存储I/O相关的队列深度要贴近硬件实际能力数据库的I/O行为与文件系统交互时操作系统层有队列深度的限制。队列深度决定了同一时间可以有多少个I/O请求在飞行。给得少了磁盘一直在等活干利用率低给得多了大量I/O请求堵在一起反而造成排队和延迟攀升。这个参数没有通用最优值必须根据你的存储类型来判断。如果是普通SATA盘的直连存储I/O能力有限队列深度配置过高没有意义只会让请求在操作系统队列里堆积如果是高端的SSD或者全闪阵列I/O能力很强配置的队列深度过低会把存储压不上去白白浪费硬件。我见过一个用的是全SSD存储的项目默认配置下数据库的I/O等待并不算异常但磁盘利用率始终只有10%左右。排查后定位就是队列深度配置偏低I/O带宽上不去调整之后批量导入快了一倍多。补偿I/O也是值得关注的一块。当缓冲池里的脏页达到一定比例时数据库会启动补偿I/O强制刷盘这个动作在业务高峰期会跟你抢I/O。如果业务允许可以适当调整触发阈值的参数让刷盘更平滑避免出现周期性的大块I/O波动。2.5 第五个策略自动统计信息要开但采集窗口要躲开高峰期优化器要生成好的执行计划靠的是统计信息。YashanDB的自动统计信息任务负责定期采样表的数据分布、索引信息等元数据。这个功能建议一直开着如果关了你可能一开始感觉不到问题但等数据量变化大了执行计划会越来越偏最后出现“明明有索引却走全表扫描”的怪事。自动采集本身也是消耗资源的。默认的采集窗口通常在业务低谷期这是合理的。但如果你没留意过这个配置默认策略可能与你的业务高峰错位。比如有些系统凌晨反而是跑批时间自动统计信息任务跟跑批任务撞在一起两边互相抢I/O跑批变慢统计信息采集也受影响。我的建议是明确设置维护窗口选一个确定没有重要任务的时段控制采样并发度。对于超大表可以关闭自动统计改为手动定期收集采集策略也改成基于增量数据的采样避免每次全量扫描。提醒统计信息的“新鲜度”是最容易被忽略的风险源。新上线一个表数据量从1万涨到1个亿旧统计信息会让优化器严重误判。在这种场景下即使自动任务开着也建议在批量导入数据结束后手工触发一次统计信息收集。2.6 第六个策略SQL游标缓存要能容纳你的典型并发数每条SQL在执行前要经过解析、绑定、生成执行计划的过程。这个过程是有成本的尤其对于复杂的SQL解析和优化可能占SQL总执行时间的相当大比例。为了减少重复解析YashanDB提供了游标缓存把已解析的SQL和执行计划缓存起来。这个参数的核心是设置缓存的条目数量而不是内存大小。如果配得小高并发下SQL被频繁挤出缓存导致不断重复解析CPU消耗明显上升配得大内存占用自然也会增加。问题是很多人不知道该设多大。实际上你可以通过查询动态视图观察游标缓存的使用率以及缓存命中失败的次数。如果发现单日累计的硬解析次数很高或者缓存重用的比例偏低就是你该加大这个参数的时候了。判断经验是先观察活跃会话数和典型并发峰值缓存条目数至少要比这个峰值高才能保证并发SQL都在缓存里。对于使用了大量动态SQL的系统这个参数更要重点关注。动态SQL往往长短不一、参数不同导致缓存的消耗比想象中快得多。某些场景下你甚至会希望把参数化SQL的开关调得更积极让更多结构相同、参数不同的SQL共用同一条缓存。2.7 第七个策略排序和哈希区大小要压制磁盘临时文件排序和哈希连接是数据库中最常见的两种需要额外内存的操作。YashanDB为这些操作分配的内存区如果不够用会溢出到磁盘临时文件性能会断崖式下跌。很多人在配这块内存时存在两个误区第一是给得过于保守默认值在分析型查询面前完全不够用复杂排序全部走磁盘第二是给得过于激进把内存几乎全分配了导致并发执行多个排序操作时内存直接不足数据库用全局等待机制控制内存使用查询全卡住。合理的做法是结合并发度和单个查询的复杂度来控制。单个查询的排序量你可以通过执行计划里的估算行数来预判。假设你的库最多同时跑10个排序操作每个排序排序的数据量大约是2G那你需要给这块区域预留至少20G的内存。并发度大就单个少配点并发度小就可以允许单个查询使用更多内存。还需要留意的是这些内存区是会话级的不是全局共享的。这意味着实际内存消耗是会话数乘以单会话配置。你配置的时候不能只看单查询需要多少还要加上并发系数否则内存很容易被撑爆。2.8 第八个策略索引配置也要回写到数据库配置里很多人以为索引是SQL层面的事情跟数据库配置无关。但实际上YashanDB的优化器是否选择某个索引跟一个关键的配置参数有关优化器是否信任索引的统计信息以及索引扫描的成本模型。这个策略的核心是让优化器更愿意使用合适的索引。如果你发现某条SQL明明有选择性很好的索引但执行计划就是走全表扫描不要急着骂优化器先看配置层面是不是把索引扫描的代价估算得太高了。一些数据库默认情况下对索引扫描的代价评估比较悲观导致优化器宁可扫全表也不走索引。此外新的索引创建后要及时收集统计信息。有些人建了索引但不更新统计信息优化器按旧数据估算以为这个索引选择性很差弃用了。这个坑我踩过不止一次后来养成了习惯任何索引变更后都主动触发统计信息更新。对于复合索引还有一个配置思路要让优化器理解列的纠偏能力即多个条件组合后数据量的急剧减少。合理的统计信息采集策略会让优化器更准确地判断组合条件的实际效果从而选中最优的索引路径。2.9 第九个策略大事务和批量操作的批处理参数要单独调事务大小对配置的要求不同。小事务追求低延迟大事务追求稳定性和可控性。YashanDB本身支持大事务但默认配置往往是小事务优先的。如果你有大量批量插入、批量更新的场景建议关注这几个方向一是撤销空间的分配策略批量操作会产生大量旧版本数据撤销空间不足最直接的表现就是“快照太旧”类报错二是日志空间的增长速度大批量操作会产生海量日志如果日志空间上限设置得太小会出现日志切换频繁、提交被阻塞的情况。我处理过一个批量导入场景每天一次大规模数据清理和导入跑了几周后偶尔会报快照过旧。排查发现有一个长时间运行的查询在跑它的读视图一直停留在旧时间点而批量更新在持续产生新版本撤销空间被占满导致旧版本被覆盖。解决办法就是对批量任务和长查询的时间窗口做隔离同时增大撤销空间上限。这里不仅改了配置还调整了任务编排。批量操作的并行度也可以单独配置。默认情况下批量操作使用的并行度跟查询共用一套配置。但批量的特点是吞吐优先、延迟不敏感可以适当把并行度调得比OLTP查询高一些而不影响日常事务的响应速度。2.10 第十个策略定期做配置审计防止“调优漂移”最后一个策略最容易被忽视配置审计。数据库的参数会被很多人改来改去有的是DBA调优改的有的是应用上线时临时改的还有的是故障处理中应急改的。半年之后你会发现自己都记不清当前配置里哪些是刻意的哪些是临时的。我建议每季度做一次配置基线审计把所有非默认参数导出来逐个核对是否有注释、是否有当时的变更记录。没有记录的非默认参数要评估是否保留。这个流程成本不高但能防止大量隐性问题的积累。更进一步配置变更要纳入版本管理。我见过不少团队用文本文件记录数据库参数变更但不统一、不完整。更好的做法是写一份初始化配置脚本所有变更通过脚本执行并留下记录数据库要是重建了一份脚本就能恢复整套调优成果。这不是配置管理洁癖而是省以后的大麻烦。没有记录的非默认参数几乎可以肯定是故障排查中的临时措施。它们往往是问题过去之后被遗忘的还在默默地影响系统行为。清理掉这些恢复到你验证过的组合是让性能回归稳定的最有效操作。3. 不同场景下的推荐配置组合3.1 轻量OLTP场景典型特征是高并发、短事务、数据量不大但对延迟敏感。这类系统的目标是让每个小事务走最短路径。推荐的关键配置组合提交策略选折中模式降低提交延迟并行度设置得保守4左右就够重点避免并行调度的额外开销数据缓冲区不需要超过活跃数据量的1.2倍游标缓存要按峰值并发配置尽量避免硬解析排序区内存不宜过大因为OLTP根本用不到复杂的排序操作减少内存浪费这个组合下TPS的大幅提升通常来自提交策略和游标缓存的调整而不是缓冲区大小。不少人误以为把缓冲区调最大就能提升OLTP性能实测下来远不如提交策略的收益明显。3.2 分析型OLAP场景典型特征是复杂查询多、并发不算特别高、单个查询跑得久。这类系统的目标是让大查询别落到磁盘上。推荐的关键配置组合并行度按物理核数的一半起步根据压测结果逐步微调寻找性能平台期排序区和哈希区内存要给足宁可降低并发数也要避免磁盘临时文件自动统计信息必须维持高频采集确保优化器有数据可用缓冲区大小可以适度放宽毕竟OLAP查询命中缓存对性能提升显著批量操作并行度可以单独调高不跟查询并行度绑定这个组合最常见的问题是内存分配失衡。我有一次调整后发现排序区内存足够大但查询还是很慢排查定位到缓冲区太小复杂查询需要反复扫描基础表物理读占满I/O。把内存从排序区匀出一部分给缓冲区后性能立刻好转。3.3 混合负载场景大多数真实系统都不是纯粹的OLTP或OLAP而是两者混合。这类场景是最难配置的因为你不能偏向任何一方。推荐策略是对资源做隔离和限制而不是统一调配。关键思路用资源组或资源计划把OLTP和OLAP的会话分在不同的资源池限制OLAP查询最高能占用多少CPU和内存并行度按资源组分别配置不共用一套值把统计信息采集窗口安排在OLAP低峰期避开OLTP的晚高峰日志相关配置按OLTP的需求来设因为事务提交的延迟影响更大排序区和哈希区按OLAP的需求预留但通过资源组限制最高使用量防止OLAP查询把内存吃光导致OLTP提交阻塞混合负载的调优没有一步到位的配置一定是在运行中持续观察调整的。每个调整都做AB对比看对两类负载的利弊影响尽量找到平衡点。4. 常见配置误区与排查心得4.1 为什么改了配置没有生效这是我最常被问到的问题“我改了参数重启了库怎么性能没变化”第一种可能是你改的这个参数在当前负载下根本不是瓶颈。你改的缓冲区大小但实际瓶颈是日志提交延迟那当然没变化。判断方法很简单看等待事件。如果发现日志相关等待占比最高你调缓冲区就是白调。第二种可能是还有另一个参数在拖后腿。改了并行度但没有调资源组的限制全局的资源管理把你压住了或者改了排序区大小但内存管理模块的总预算没变其他模块把内存瓜分完了。第三种可能是你的配置没真正生效。YashanDB有参数级别之分有的参数需要重启数据库有的动态即可调整。修改后要确认状态不要想当然认为已经生效。4.2 性能问题不一定都是配置的锅配置调优做得再好SQL写成那样也白搭。我见过太多案例全表扫描的SQL加上巨大的排序操作再好的数据库配置也只是把灾难从1秒变成0.9秒。遇到性能问题正确的排查顺序是先看SQL和执行计划再看统计信息是否新鲜然后看等待事件最后才动配置。配置调优是上层建筑SQL质量才是地基。地基不牢上层调什么都是空的。4.3 参数不一定越大越好越大往往有副作用我踩过的坑里印象最深的是盲目调大参数。缓冲区开太大内存不足导致操作系统开始换页并行度开太高调度开销比计算本身还大日志缓冲给得过于激进内存被白白占用但性能没有提升。任何配置改动都应该带着预期上的假设去测试而不是抱着“多给点总没错”的心态。数据库是精密系统各个模块相互制约牵一发而动全身。每次只改一个参数记录前后对比这是唯一靠谱的方法。4.4 压测和真实负载的差距还有一个常见的坑压测环境怎么调都好上线就拉胯。原因是压测负载太理想化真实负载有高峰有低峰有并发突刺有慢SQL拖累。配置调优不能只盯着压测数据还要在真实负载下持续观察。我一贯的做法是压测验证基础的配置正确性上线后继续观察AWR和等待事件头两周特别关注非高峰期有没有隐藏的问题比如后台任务集中启动造成的资源争抢。5. 一次真实调优案例的全过程最后分享一个完整的调优案例展示上面这些策略是怎么组合起来落地的。某系统的数据库16核CPU、128G内存业务是典型的混合负载既有在线交易又有报表查询。上线初期性能不理想交易高峰时报表查询一跑交易延迟明显上升。第一步先采集了基线数据确认瓶颈。发现日志提交的等待占比接近40%排序相关等待占比接近20%缓冲区命中率有96%并不算差。由此判断主要问题不在缓冲而在提交策略和排序内存。第二步调整提交策略到折中模式日志等待立刻下降交易延迟从平均8毫秒降到2毫秒左右。然后调整排序区内存报表查询的磁盘临时文件数量明显减少整体查询时间缩短了一半。第三步对报表类查询单独配置了资源组限制限制它们并发时的CPU占用不能超过总核数的一半。交易高峰时报表查询仍然能跑但不会再挤占核心交易路径的资源。第四步微调了并行度和游标缓存。报表查询的并行度从默认调低到8减少调度开销游标缓存翻倍硬解析占比从大约15%降到3%以下。系统整体CPU占用下降有了更多余量应对业务增长。这套组合配置上线后运行了一个月交易延迟稳定在2毫秒左右报表查询再也没有出现跟交易抢资源的情况。后续每两周查看一次等待事件根据数据走势做小幅修正。这个案例里没有一步到位的“神配置”只有针对真实等待事件做的一组合理调整这才是调优的本质。如果你正准备给自己的YashanDB做性能调优我的建议很简单先采集基线再按瓶颈逐项调整配置变更都留记录。按这十个策略逐个过一遍你的系统性能大概率会比现在提升一个台阶。
直接说结论YashanDB用得好不好很多时候真不是硬件的问题是配置的问题。我见过不少项目机器配置堆得很高但跑起来就是卡排查到最后发现是内存没分配好、并行度乱开、提交策略全默认。反过来有的项目硬件一般但调优做到位了性能直接翻倍。这篇就把我在实际项目中用YashanDB总结出来的10个配置策略掰开揉碎讲清楚每个都会说原理、给参数、讲适用场景最后还有避坑经验照着抄就行。1. 调优前必须想清楚的三件事1.1 先搞清楚你的负载类型很多人一上来就查参数、改配置这其实顺序反了。调优的第一步不是动参数而是搞清楚你的系统到底在忙什么。YashanDB和大多数数据库一样负载大致可以分为两类OLTP在线事务处理和OLAP在线分析处理。OLTP的特点是短平快事务多、单条SQL快、并发高核心痛点是延迟和并发冲突OLAP的特点是复杂查询多、扫描数据量大、跑得久核心痛点是吞吐和资源利用率。这两类负载对配置的需求完全相反OLTP需要更大的日志缓冲、更激进的事务提交策略、适度并行度OLAP则需要更大的排序区、哈希区、扫描缓冲区以及更高的并行度。你如果拿OLAP的配置去跑OLTP业务最直接的结果就是小事务慢得让人抓狂。我的习惯是拿到一个库先不做任何调整跑一周的负载采集AWR报告看TOP事件到底卡在什么地方。绝大部分情况下问题不在某个单一参数而是配置组合与负载类型不匹配。1.2 确认硬件资源的天花板配置不是越高越好所有参数都有物理边界。你得先确认机器到底有多少CPU核数、多少内存、什么样的存储。对于内存还要注意一个关键点数据库能用的内存不是你机器总内存要留出操作系统本身运行的余量。我一般建议数据库的内存规划占物理内存的50%到70%具体比例取决于这台机器是否还跑别的服务。CPU方面要看的是物理核数不是逻辑核数超线程带来的逻辑核在数据库高并发场景下不总能带来线性收益。存储这块最容易被忽略。不少人默认配了最大I/O能力但实际上你的磁盘根本扛不住。调优前最好用工具测一测随机的读写延迟和顺序读带宽心里有个底后面配I/O相关参数时才不会拍脑袋。1.3 建立性能基线再动手这是我最想强调的一点调优之前先记录下当前所有的关键性能指标。包括但不限于TPS、QPS、平均延迟、P99延迟、缓存命中率、磁盘I/O等待、活跃会话数等。没有基线的调优等于闭着眼睛开车。你改了一个参数性能确实提升了但你不知道提升到底来自这个参数还是其他因素更糟糕的是同时改了好几个参数出问题了都不知是谁的锅。我个人的习惯是用压测工具先跑20分钟标准负载记录所有指标然后每次只改一个参数再跑同样的负载对比前后差异。调优是科学实验不是玄学。2. 十个配置策略的底层逻辑2.1 第一个策略内存参数要按业务数据量配而不是按机器大小配很多人配YashanDB是这样做的机器有256G内存就把数据缓冲区设成192G觉得这就叫充分利用。这个做法在一半场景下是错的。数据缓冲区的核心作用是缓存热点数据块减少物理I/O。它的最优大小取决于两个因素活跃数据总量和访问的局部性。如果你的业务活跃数据就30G你给它190G的缓冲区多余的部分对性能没有额外帮助反而会占用其他模块如排序区、哈希区可用的内存反过来活跃数据有200G你只给它64G那命中率肯定上不去物理读自然多。我的习惯是先看数据量再看访问分布。如果查询基本都命中一个2G的热点表那给64G和192G的效果几乎一样。判断标准就是看缓冲区命中率YashanDB的动态视图里可以查到。低于95%说明缓冲不够或者访问太分散接近100%也未必是好事至少说明你给的内存超过了实际需求可以把内存省给其他部分。另外一个常见的反模式是把所有内存都给数据缓冲区忽略排序区、哈希区、日志缓冲区等。数据库的各个内存组件是要协同工作的某一块特别大不代表性能就好反而可能导致其他模块频繁溢出到磁盘造成严重的性能抖动。注意内存参数修改后通常需要重启数据库才能生效。在YashanDB中部分内存参数支持动态调整但扩展到更大值往往需要预留足够内存。生产环境修改前一定先评估重启窗口。2.2 第二个策略日志和提交策略决定事务延迟的上限事务提交是OLTP场景最频繁发生的操作也是延迟最敏感的操作。YashanDB的日志提交策略直接决定了每次事务提交的磁盘同步次数和等待时长。这个策略的核心参数控制着日志写入的刷盘方式。简单来说有两种极端模式一种是最保险的模式每次提交都把日志稳稳刷到磁盘上再返回成功数据绝对不会丢但延迟通常是最高的另一种是收益最快的模式日志先在内存里存够一定量再批量刷到磁盘事务提交延迟很低但如果出现宕机最近一小段已提交事务的数据可能会丢失。大部分OLTP系统不必选极端模式。更推荐的是折中方案事务提交时通知日志写进程开始刷盘但不等确认结果就返回成功。这种方式能把延迟压下来同时把丢失窗口压缩到极小。如果你的业务确实无法容忍任何丢失再考虑最保险的模式。我调过的一个某交易系统原来用的全同步模式平均提交延迟在8毫秒左右TPS大概三千多。改成折中方案后延迟降到1.5毫秒TPS直接翻倍还多。业务方几乎没有任何感知因为他们的系统设计本身已经考虑了重复提交的幂等性。另一个值得配的参数是日志缓冲的大小。在写入高峰期如果日志缓冲太小写日志的线程会频繁等待造成提交阻塞。一般建议至少配置到几MB级别如果单事务产生日志较多可以配到十几MB甚至更高。这个参数不用太大太大不仅浪费内存对性能也没什么额外好处。2.3 第三个策略并行度不是核数越多越快在YashanDB里并行查询的默认并行度往往并不理想。很多人直接把它设成跟CPU核数一样觉得这样能充分利用硬件。但实际测试下来并行度过高反而会让性能跳水。原因是并行查询需要把数据分片每个分片由一个并行服务进程处理最后还要汇总结果。分片和汇总的过程都有开销。在OLTP负载下事务本身就很轻量强行并行不仅没有收益反而增加了进程调度的开销和资源争抢。在OLAP负载下并行度也不是越高越好超过某个阈值后I/O和内存带宽会成为瓶颈再往上加核数只是空转。我的经验值是OLTP业务建议把并行度控制在4到8之间OLAP场景可以尝试按CPU核数的一半起配然后逐步加压测试到性能平台期为止。判断依据就是看并行服务的等待事件占比如果发现大量的并行空闲说明并行度开高了。另外日志写入、备份恢复这些后台任务也都有自己的并行度参数可以单独配置。不要为了查询性能把备份并行度也调得很高否则业务高峰期备份任务会把I/O带宽吃掉造成业务查询性能抖动。2.4 第四个策略存储I/O相关的队列深度要贴近硬件实际能力数据库的I/O行为与文件系统交互时操作系统层有队列深度的限制。队列深度决定了同一时间可以有多少个I/O请求在飞行。给得少了磁盘一直在等活干利用率低给得多了大量I/O请求堵在一起反而造成排队和延迟攀升。这个参数没有通用最优值必须根据你的存储类型来判断。如果是普通SATA盘的直连存储I/O能力有限队列深度配置过高没有意义只会让请求在操作系统队列里堆积如果是高端的SSD或者全闪阵列I/O能力很强配置的队列深度过低会把存储压不上去白白浪费硬件。我见过一个用的是全SSD存储的项目默认配置下数据库的I/O等待并不算异常但磁盘利用率始终只有10%左右。排查后定位就是队列深度配置偏低I/O带宽上不去调整之后批量导入快了一倍多。补偿I/O也是值得关注的一块。当缓冲池里的脏页达到一定比例时数据库会启动补偿I/O强制刷盘这个动作在业务高峰期会跟你抢I/O。如果业务允许可以适当调整触发阈值的参数让刷盘更平滑避免出现周期性的大块I/O波动。2.5 第五个策略自动统计信息要开但采集窗口要躲开高峰期优化器要生成好的执行计划靠的是统计信息。YashanDB的自动统计信息任务负责定期采样表的数据分布、索引信息等元数据。这个功能建议一直开着如果关了你可能一开始感觉不到问题但等数据量变化大了执行计划会越来越偏最后出现“明明有索引却走全表扫描”的怪事。自动采集本身也是消耗资源的。默认的采集窗口通常在业务低谷期这是合理的。但如果你没留意过这个配置默认策略可能与你的业务高峰错位。比如有些系统凌晨反而是跑批时间自动统计信息任务跟跑批任务撞在一起两边互相抢I/O跑批变慢统计信息采集也受影响。我的建议是明确设置维护窗口选一个确定没有重要任务的时段控制采样并发度。对于超大表可以关闭自动统计改为手动定期收集采集策略也改成基于增量数据的采样避免每次全量扫描。提醒统计信息的“新鲜度”是最容易被忽略的风险源。新上线一个表数据量从1万涨到1个亿旧统计信息会让优化器严重误判。在这种场景下即使自动任务开着也建议在批量导入数据结束后手工触发一次统计信息收集。2.6 第六个策略SQL游标缓存要能容纳你的典型并发数每条SQL在执行前要经过解析、绑定、生成执行计划的过程。这个过程是有成本的尤其对于复杂的SQL解析和优化可能占SQL总执行时间的相当大比例。为了减少重复解析YashanDB提供了游标缓存把已解析的SQL和执行计划缓存起来。这个参数的核心是设置缓存的条目数量而不是内存大小。如果配得小高并发下SQL被频繁挤出缓存导致不断重复解析CPU消耗明显上升配得大内存占用自然也会增加。问题是很多人不知道该设多大。实际上你可以通过查询动态视图观察游标缓存的使用率以及缓存命中失败的次数。如果发现单日累计的硬解析次数很高或者缓存重用的比例偏低就是你该加大这个参数的时候了。判断经验是先观察活跃会话数和典型并发峰值缓存条目数至少要比这个峰值高才能保证并发SQL都在缓存里。对于使用了大量动态SQL的系统这个参数更要重点关注。动态SQL往往长短不一、参数不同导致缓存的消耗比想象中快得多。某些场景下你甚至会希望把参数化SQL的开关调得更积极让更多结构相同、参数不同的SQL共用同一条缓存。2.7 第七个策略排序和哈希区大小要压制磁盘临时文件排序和哈希连接是数据库中最常见的两种需要额外内存的操作。YashanDB为这些操作分配的内存区如果不够用会溢出到磁盘临时文件性能会断崖式下跌。很多人在配这块内存时存在两个误区第一是给得过于保守默认值在分析型查询面前完全不够用复杂排序全部走磁盘第二是给得过于激进把内存几乎全分配了导致并发执行多个排序操作时内存直接不足数据库用全局等待机制控制内存使用查询全卡住。合理的做法是结合并发度和单个查询的复杂度来控制。单个查询的排序量你可以通过执行计划里的估算行数来预判。假设你的库最多同时跑10个排序操作每个排序排序的数据量大约是2G那你需要给这块区域预留至少20G的内存。并发度大就单个少配点并发度小就可以允许单个查询使用更多内存。还需要留意的是这些内存区是会话级的不是全局共享的。这意味着实际内存消耗是会话数乘以单会话配置。你配置的时候不能只看单查询需要多少还要加上并发系数否则内存很容易被撑爆。2.8 第八个策略索引配置也要回写到数据库配置里很多人以为索引是SQL层面的事情跟数据库配置无关。但实际上YashanDB的优化器是否选择某个索引跟一个关键的配置参数有关优化器是否信任索引的统计信息以及索引扫描的成本模型。这个策略的核心是让优化器更愿意使用合适的索引。如果你发现某条SQL明明有选择性很好的索引但执行计划就是走全表扫描不要急着骂优化器先看配置层面是不是把索引扫描的代价估算得太高了。一些数据库默认情况下对索引扫描的代价评估比较悲观导致优化器宁可扫全表也不走索引。此外新的索引创建后要及时收集统计信息。有些人建了索引但不更新统计信息优化器按旧数据估算以为这个索引选择性很差弃用了。这个坑我踩过不止一次后来养成了习惯任何索引变更后都主动触发统计信息更新。对于复合索引还有一个配置思路要让优化器理解列的纠偏能力即多个条件组合后数据量的急剧减少。合理的统计信息采集策略会让优化器更准确地判断组合条件的实际效果从而选中最优的索引路径。2.9 第九个策略大事务和批量操作的批处理参数要单独调事务大小对配置的要求不同。小事务追求低延迟大事务追求稳定性和可控性。YashanDB本身支持大事务但默认配置往往是小事务优先的。如果你有大量批量插入、批量更新的场景建议关注这几个方向一是撤销空间的分配策略批量操作会产生大量旧版本数据撤销空间不足最直接的表现就是“快照太旧”类报错二是日志空间的增长速度大批量操作会产生海量日志如果日志空间上限设置得太小会出现日志切换频繁、提交被阻塞的情况。我处理过一个批量导入场景每天一次大规模数据清理和导入跑了几周后偶尔会报快照过旧。排查发现有一个长时间运行的查询在跑它的读视图一直停留在旧时间点而批量更新在持续产生新版本撤销空间被占满导致旧版本被覆盖。解决办法就是对批量任务和长查询的时间窗口做隔离同时增大撤销空间上限。这里不仅改了配置还调整了任务编排。批量操作的并行度也可以单独配置。默认情况下批量操作使用的并行度跟查询共用一套配置。但批量的特点是吞吐优先、延迟不敏感可以适当把并行度调得比OLTP查询高一些而不影响日常事务的响应速度。2.10 第十个策略定期做配置审计防止“调优漂移”最后一个策略最容易被忽视配置审计。数据库的参数会被很多人改来改去有的是DBA调优改的有的是应用上线时临时改的还有的是故障处理中应急改的。半年之后你会发现自己都记不清当前配置里哪些是刻意的哪些是临时的。我建议每季度做一次配置基线审计把所有非默认参数导出来逐个核对是否有注释、是否有当时的变更记录。没有记录的非默认参数要评估是否保留。这个流程成本不高但能防止大量隐性问题的积累。更进一步配置变更要纳入版本管理。我见过不少团队用文本文件记录数据库参数变更但不统一、不完整。更好的做法是写一份初始化配置脚本所有变更通过脚本执行并留下记录数据库要是重建了一份脚本就能恢复整套调优成果。这不是配置管理洁癖而是省以后的大麻烦。没有记录的非默认参数几乎可以肯定是故障排查中的临时措施。它们往往是问题过去之后被遗忘的还在默默地影响系统行为。清理掉这些恢复到你验证过的组合是让性能回归稳定的最有效操作。3. 不同场景下的推荐配置组合3.1 轻量OLTP场景典型特征是高并发、短事务、数据量不大但对延迟敏感。这类系统的目标是让每个小事务走最短路径。推荐的关键配置组合提交策略选折中模式降低提交延迟并行度设置得保守4左右就够重点避免并行调度的额外开销数据缓冲区不需要超过活跃数据量的1.2倍游标缓存要按峰值并发配置尽量避免硬解析排序区内存不宜过大因为OLTP根本用不到复杂的排序操作减少内存浪费这个组合下TPS的大幅提升通常来自提交策略和游标缓存的调整而不是缓冲区大小。不少人误以为把缓冲区调最大就能提升OLTP性能实测下来远不如提交策略的收益明显。3.2 分析型OLAP场景典型特征是复杂查询多、并发不算特别高、单个查询跑得久。这类系统的目标是让大查询别落到磁盘上。推荐的关键配置组合并行度按物理核数的一半起步根据压测结果逐步微调寻找性能平台期排序区和哈希区内存要给足宁可降低并发数也要避免磁盘临时文件自动统计信息必须维持高频采集确保优化器有数据可用缓冲区大小可以适度放宽毕竟OLAP查询命中缓存对性能提升显著批量操作并行度可以单独调高不跟查询并行度绑定这个组合最常见的问题是内存分配失衡。我有一次调整后发现排序区内存足够大但查询还是很慢排查定位到缓冲区太小复杂查询需要反复扫描基础表物理读占满I/O。把内存从排序区匀出一部分给缓冲区后性能立刻好转。3.3 混合负载场景大多数真实系统都不是纯粹的OLTP或OLAP而是两者混合。这类场景是最难配置的因为你不能偏向任何一方。推荐策略是对资源做隔离和限制而不是统一调配。关键思路用资源组或资源计划把OLTP和OLAP的会话分在不同的资源池限制OLAP查询最高能占用多少CPU和内存并行度按资源组分别配置不共用一套值把统计信息采集窗口安排在OLAP低峰期避开OLTP的晚高峰日志相关配置按OLTP的需求来设因为事务提交的延迟影响更大排序区和哈希区按OLAP的需求预留但通过资源组限制最高使用量防止OLAP查询把内存吃光导致OLTP提交阻塞混合负载的调优没有一步到位的配置一定是在运行中持续观察调整的。每个调整都做AB对比看对两类负载的利弊影响尽量找到平衡点。4. 常见配置误区与排查心得4.1 为什么改了配置没有生效这是我最常被问到的问题“我改了参数重启了库怎么性能没变化”第一种可能是你改的这个参数在当前负载下根本不是瓶颈。你改的缓冲区大小但实际瓶颈是日志提交延迟那当然没变化。判断方法很简单看等待事件。如果发现日志相关等待占比最高你调缓冲区就是白调。第二种可能是还有另一个参数在拖后腿。改了并行度但没有调资源组的限制全局的资源管理把你压住了或者改了排序区大小但内存管理模块的总预算没变其他模块把内存瓜分完了。第三种可能是你的配置没真正生效。YashanDB有参数级别之分有的参数需要重启数据库有的动态即可调整。修改后要确认状态不要想当然认为已经生效。4.2 性能问题不一定都是配置的锅配置调优做得再好SQL写成那样也白搭。我见过太多案例全表扫描的SQL加上巨大的排序操作再好的数据库配置也只是把灾难从1秒变成0.9秒。遇到性能问题正确的排查顺序是先看SQL和执行计划再看统计信息是否新鲜然后看等待事件最后才动配置。配置调优是上层建筑SQL质量才是地基。地基不牢上层调什么都是空的。4.3 参数不一定越大越好越大往往有副作用我踩过的坑里印象最深的是盲目调大参数。缓冲区开太大内存不足导致操作系统开始换页并行度开太高调度开销比计算本身还大日志缓冲给得过于激进内存被白白占用但性能没有提升。任何配置改动都应该带着预期上的假设去测试而不是抱着“多给点总没错”的心态。数据库是精密系统各个模块相互制约牵一发而动全身。每次只改一个参数记录前后对比这是唯一靠谱的方法。4.4 压测和真实负载的差距还有一个常见的坑压测环境怎么调都好上线就拉胯。原因是压测负载太理想化真实负载有高峰有低峰有并发突刺有慢SQL拖累。配置调优不能只盯着压测数据还要在真实负载下持续观察。我一贯的做法是压测验证基础的配置正确性上线后继续观察AWR和等待事件头两周特别关注非高峰期有没有隐藏的问题比如后台任务集中启动造成的资源争抢。5. 一次真实调优案例的全过程最后分享一个完整的调优案例展示上面这些策略是怎么组合起来落地的。某系统的数据库16核CPU、128G内存业务是典型的混合负载既有在线交易又有报表查询。上线初期性能不理想交易高峰时报表查询一跑交易延迟明显上升。第一步先采集了基线数据确认瓶颈。发现日志提交的等待占比接近40%排序相关等待占比接近20%缓冲区命中率有96%并不算差。由此判断主要问题不在缓冲而在提交策略和排序内存。第二步调整提交策略到折中模式日志等待立刻下降交易延迟从平均8毫秒降到2毫秒左右。然后调整排序区内存报表查询的磁盘临时文件数量明显减少整体查询时间缩短了一半。第三步对报表类查询单独配置了资源组限制限制它们并发时的CPU占用不能超过总核数的一半。交易高峰时报表查询仍然能跑但不会再挤占核心交易路径的资源。第四步微调了并行度和游标缓存。报表查询的并行度从默认调低到8减少调度开销游标缓存翻倍硬解析占比从大约15%降到3%以下。系统整体CPU占用下降有了更多余量应对业务增长。这套组合配置上线后运行了一个月交易延迟稳定在2毫秒左右报表查询再也没有出现跟交易抢资源的情况。后续每两周查看一次等待事件根据数据走势做小幅修正。这个案例里没有一步到位的“神配置”只有针对真实等待事件做的一组合理调整这才是调优的本质。如果你正准备给自己的YashanDB做性能调优我的建议很简单先采集基线再按瓶颈逐项调整配置变更都留记录。按这十个策略逐个过一遍你的系统性能大概率会比现在提升一个台阶。
