做了这么多年数据库开发和运维最常被问的问题之一就是同样一张几百万行的表为什么在别人的库里跑得飞快到自己手里就慢成蜗牛最近我把一套历史数据量不小的业务库整体迁移到了YashanDB上折腾了一段时间后发现提升数据处理效率这件事其实不靠什么玄学配置而是靠几个非常具体的实操技巧。这篇内容我就围绕YashanDB梳理5个立竿见影的技巧覆盖批量操作、执行计划、索引设计、分区表、统计信息与并行度。不需要你一开始就懂很深的内核原理只要你手里有一个能跑SQL的YashanDB环境或者正在纠结怎么把现有系统上的慢SQL救回来这篇文章都能直接给你操作路径。我会把每一步为什么这么做、做完能看到什么效果、有哪些坑要躲都讲清楚。1. 写在前面从一次数据处理卡顿说起1.1 一个真实的场景几百万行数据为什么跑不动之前我接手过一套业务统计系统里头有一张订单流水表数据量其实并不夸张单表一千万行左右按时间字段做了常用查询。业务上需要经常做时间范围内的汇总统计还要和用户维度表做关联每次跑一次月度汇总要四五分钟稍微把时间范围拉长一点直接奔着十分钟去。领导不满意业务方天天催我一开始也以为是数据库选型出了问题甚至考虑过要不要上一套更重的分析引擎。后来我静下心来做排查发现问题的根子压根不在数据库本身而在SQL写法和表设计上。那张流水表上没有针对时间范围查询的合适索引统计SQL里还存在把时间列包在函数里导致索引失效的情况最离谱的是数据导入的过程用应用层一条一条INSERT一个小任务跑了几个小时。这些问题改完之后同样的汇总查询从几分钟降到了十几秒数据导入时间从小时级降到了分钟级。这件事让我印象很深大部分数据处理效率问题不是靠换数据库或者加硬件解决的而是把数据库的正确使用方式吃透。YashanDB作为一个兼容常用SQL语法的数据库系统很多通用方法论完全适用但也有些细节需要结合它自身的行为特征来调整。1.2 为什么是这5个技巧我梳理的这5个技巧覆盖了数据工程师和DBA在日常工作中遇到的大部分效率瓶颈批量操作解决的是“单条处理太慢”的吞吐问题执行计划解决的是“SQL走错路”的路径问题索引设计解决的是“数据检索太慢”的访问问题分区表解决的是“数据量太大不好管”的治理问题统计信息与并行度解决的是“优化器瞎猜和资源用不满”的调度问题这5个技巧有一个共同的优点它们都不需要改动业务架构不需要重写整个应用只要你愿意花半天时间检查自己手头的慢SQL和表结构就能看到效果。接下来的内容我每个技巧都会从原理、实操、避坑三个角度来讲。2. 技巧一批量操作替代逐行处理2.1 逐行处理为什么慢很多数据处理任务慢根本不是查询慢而是写入量太大。最常见的一种写法就是在应用层写一个循环遍历Excel或者接口返回的数据集然后一条一条执行INSERT或者UPDATE。这种写法在数据量只有几百条的时候感觉不到问题一旦数据量到了几万、几十万性能就会断崖式下跌。逐行处理的代价要从两个层面看。第一层是网络和协议开销每执行一条SQL应用和数据库之间就要经历一次完整的请求-响应往返哪怕是内网一次往返也有几十微秒到几毫秒的固定成本一万条数据就是一万次往返。第二层是事务开销每条INSERT自带一个隐式事务每一条都要写日志、都要做提交确认这个固定成本比SQL执行本身还要高。我做过一个简单测算假设单条INSERT在本地环境耗时1毫秒一万条就是10秒。如果把INSERT改成每500条作为一个批次统一提交网络往返从一万次降到20次事务提交从一万次降到20次总耗时很可能直接降到几百毫秒级别提升幅度是几十倍。这种优化不需要任何高级配置纯粹是使用方式的问题。2.2 具体落地方式与分批策略在YashanDB里做批量写入我常用的方式有两种。第一种是程序里的分批提交。不管是用Python、Java还是其他语言不要让数据库驱动自动提交而是先把自动提交关掉每累积到一定行数再统一COMMIT。以Python为例大致是这么个思路batch_size 500 count 0 for row in data_source: cursor.execute(insert_sql, row) count 1 if count % batch_size 0: connection.commit() connection.commit()第二种是SQL层面的多行VALUES。也就是一条INSERT语句后面跟多个元组INSERT INTO order_flow (order_id, user_id, amount, create_time) VALUES (1001, 2001, 99.00, TIMESTAMP 2025-01-01 10:00:00), (1002, 2002, 128.00, TIMESTAMP 2025-01-01 10:00:01), (1003, 2003, 59.90, TIMESTAMP 2025-01-01 10:00:02);这种写法特别适合从文件或者临时表加载数据一次性把几百行甚至几千行拼接成一个INSERT。实际测试下来YashanDB对多行VALUES的批量扩展支持得不错单条语句带上几百行数据执行效率明显优于逐条写入。这里要提醒一下批量大小不是越大越好。一个批次太大会把事务持续时间拉得很长锁的范围会变大日志量也会在提交时集中爆发而且一旦中途失败回滚的成本非常高。我自己用得比较多的是每批次300到1000行具体要看单行字段的复杂度和实际压测结果。2.3 批量操作的几个坑批量操作看起来简单实际操作中有几个细节容易踩坑。第一个坑是事务粒度和业务一致性之间的平衡。如果你在做一个需要严格校验的数据导入可能必须在某几条数据失败时只回滚这几条而不是整个批次全部回滚。这时候可以把批次大小调小比如50条一批或者采用保存点。不要为了性能把一致性需求搞丢。第二个坑是大量DELETE和UPDATE同样需要分批。很多人只注意INSERT要批量却忽略了清理数据时一条DELETE扫全表、几千万行一次性删除会长时间占用资源和锁。删除大数据量时建议循环分批删除每批删除几千行然后提交既能避免长事务也能减少对在线业务的影响。第三个坑是批量导入场景和事务日志的配合。大批量数据加载时如果开着很多无关索引写入性能会被索引维护拖累。我通常在导数据之前临时禁用或删除非必要索引导完再重建整体耗时反而更短。3. 技巧二学会用执行计划做SQL体检3.1 怎么拿到YashanDB的执行计划如果一条SQL跑到怀疑人生第一步不是去猜原因而是看它的执行计划。执行计划就是优化器为这条SQL选出来的执行路线它决定了先访问哪张表、用什么方式访问、怎么连接、在哪个阶段过滤数据。YashanDB的执行计划获取方式沿用了常见的数据库习惯大致可以用这种形式EXPLAIN PLAN FOR SELECT o.user_id, u.user_name, SUM(o.amount) FROM order_flow o JOIN user_dim u ON o.user_id u.user_id WHERE o.create_time TIMESTAMP 2025-01-01 AND o.create_time TIMESTAMP 2025-02-01 GROUP BY o.user_id, u.user_name;然后通过查询计划展示视图来读取结果。不同版本的具体视图名可能略有差异如果不确定可以直接连数据库工具看图形化执行计划或者查一下当前版本的说明文档。拿到执行计划之后第一件事是搞清楚计划里的关键节点访问路径是走的索引还是全表扫描连接方式是嵌套循环还是哈希连接排序发生在哪个阶段有没有做分区裁剪。这几个点基本决定了一条SQL是快是慢。3.2 执行计划里到底要看什么很多人拿到执行计划就开始懵觉得节点太多、看不懂。其实对我们做优化来说不需要把每个细节都吃透重点关注四类问题就够了。第一类是访问路径问题。大表上的条件过滤如果显示的是全表扫描而且表很大那多半需要检查索引是否存在、条件是否真的能用上索引。第二类是连接顺序问题。多表关联的时候小表作为驱动表、大表被驱动是更常见的合理路径如果发现优化器拿大表去驱动小表连接中间结果集就会特别大。第三类是排序问题。计划里出现SORT ORDER BY或者SORT GROUP BY意味着数据要在内存或磁盘里做排序如果结果集很大这一步往往是性能瓶颈。第四类是基数估算问题。优化器估算返回行数和实际行数差太多通常说明统计信息不准确这时候执行计划路径选错也就不奇怪了。我自己的习惯是看计划时拿一张纸把“访问路径”、“连接方式”、“过滤时机”、“排序位置”四个词写在边上一个一个对着找答案。绝大多数慢SQL看完整张计划之后慢在哪里就已经有眉目了。3.3 一个慢SQL优化实例之前遇到一条统计SQL功能是统计某个月内每个用户的订单总额。原SQL写法上有一个很典型的错误在WHERE条件里把时间字段用函数包了一层。类似这样WHERE TO_CHAR(o.create_time, YYYY-MM) 2025-01这种写法从业务逻辑上看完全没错但从优化器的角度create_time上的索引基本就废了。因为索引里存储的是原始的时间值而你拿一个转换后的字符串去做匹配优化器没法直接把索引区间映射上去只能老老实实做全表扫描再把每一行的create_time转成字符串最后比对。一个月的数据有几百万行全表扫一遍再转字符串耗时自然高。改成范围条件之后情况完全不一样WHERE o.create_time TIMESTAMP 2025-01-01 AND o.create_time TIMESTAMP 2025-02-01配合create_time上的索引优化器可以直接锁定一月份的数据区间扫描量从全表变成一个月的数据块。再加上user_id上的索引或合适的复合索引关联部分也能受益。那条SQL最终从几十秒降到了两三秒。这里面最值得记住的一点是执行计划不会说谎慢SQL的病因基本都能在计划里找到。别靠猜让计划说话。4. 技巧三索引设计多快好省的关键4.1 索引选型不是越多越好很多人一提到优化就说加索引这是一种很危险的习惯。索引的本质是拿写入和维护的成本换查询的速度每多一个索引每次INSERT、UPDATE、DELETE都要多维护一份数据结构表越大维护成本越高。不加思考地随意加索引很可能让查询没快多少反而把写入拖慢。索引设计的第一步是分析查询模式。高频查询的条件有哪些哪些列经常出现在WHERE后面哪些列是等值匹配哪些列是范围匹配。等值匹配的列适合放复合索引的前列范围匹配的列适合放后面。低基数列要谨慎比如性别、状态这种只有几个取值的列普通B树索引的选择性很差优化器很多时候反而不愿意走这个索引。我在YashanDB上建索引的经验是优先为高频慢查询建索引不为“可能有用”建索引。每建一个索引都要问自己三个问题这个索引能覆盖哪几条高频SQL它的维护成本能不能接受有没有和现有索引重复回答不清楚就不要建。4.2 复合索引与函数索引的使用细节复合索引的列顺序是一门很实在的学问。假设业务查询经常用user_id和create_time两个条件那么创建(user_id, create_time)的复合索引和创建(create_time, user_id)的复合索引表现完全不同。如果查询条件是user_id等值匹配、create_time范围匹配前者非常合适后者可能完全用不上。复合索引还有一个常用技巧叫覆盖索引。如果查询需要返回的字段都包含在索引列里优化器可以直接从索引里取数连回表都省了。比如一个查询只需要ORDER_ID、USER_ID、AMOUNT而索引恰好包含这三列执行计划里就是INDEX FULL SCAN或INDEX FAST FULL SCAN不需要回表。这种收益在高频查询里非常可观。函数索引解决的是另一类问题。有时候业务上就是需要按日期格式化后的字符串做等值匹配或者按某个计算字段做过滤。YashanDB的常见做法是创建一个函数索引把表达式建到索引里。但函数索引有一个隐藏代价每次写入都要重新计算函数值所以只建议在高频查询且数据量大的场景使用小表或者低频查询就没必要了。4.3 索引失效的排查方法索引失效是数据库优化里最让人头疼的问题之一。同样的WHERE条件换个写法索引就从“走”变成“不走”。最常见的几个失效场景对索引列做函数运算比如SUBSTR或者TO_CHAR索引列和传入参数的类型不一致导致隐式转换LIKE匹配用了前导通配符比如%keyOR条件里有非索引列参与。这些情况从执行计划里一眼就能看出来应该走索引的地方变成了全表扫描。如果要排查到底为什么没走索引我的办法是拿简化后的SQL一层层测试。先把复杂的JOIN去掉只保留单表查询看能不能走索引然后逐步加回条件观察哪一步让计划改变。这样很快就能锁定是哪一条条件导致的失效。还有一个容易被忽略的点即使索引存在如果统计信息太旧优化器误以为全表扫描更便宜也会弃用索引这种情况更新统计信息就能解决。5. 技巧四分区表让大数据量管理更从容5.1 分区策略怎么选数据量一旦到了千万级以上单表查询靠索引还能硬扛一阵但数据维护就成了噩梦删除三个月前的数据要DELETE几百万行建索引的时间也越来越长。分区表这时候就是最实际的手段。YashanDB支持常见的主流分区方式范围分区、列表分区、哈希分区。范围分区最常用于时间字段比如按月、按季度把流水表拆成多个分区列表分区适合按业务属性分比如按区域代码分区哈希分区适合没有自然分组但数据量大、想均匀打散的场景。以订单流水表为例按月做范围分区是典型的做法CREATE TABLE order_flow ( order_id NUMBER, user_id NUMBER, amount NUMBER, create_time TIMESTAMP ) PARTITION BY RANGE (create_time) ( PARTITION p202501 VALUES LESS THAN (TIMESTAMP 2025-02-01), PARTITION p202502 VALUES LESS THAN (TIMESTAMP 2025-03-01), PARTITION p202503 VALUES LESS THAN (TIMESTAMP 2025-04-01) );这样建完表每个月的数据落在独立分区里查询如果带上时间条件优化器可以直接定位到对应分区连扫描范围都能缩小。5.2 分区裁剪是如何生效的分区表最大的性能红利来自分区裁剪。所谓裁剪就是SQL的WHERE条件能匹配到具体一个或几个分区时优化器只扫描这些分区其他分区连碰都不碰。裁剪生效的前提是查询条件里必须带上分区键。比如上面那张按月分区的表如果查询条件是create_time between某个月的范围优化器就能直接锁定期望的分区但如果查询条件只写了user_id没带create_time那所有分区都要扫一遍性能还不如普通小表。所以分区键的选择一定要和业务查询习惯对齐分区键如果是时间那几乎所有高频查询都应该带上时间范围。判断裁剪有没有生效还是得看执行计划。计划里如果出现分区相关的迭代器而且范围缩到了具体分区说明裁剪生效了如果看到遍历所有分区的节点就要回头检查WHERE条件。这种细节不看计划根本发现不了。5.3 分区维护的实操细节分区表不只是查询快维护也方便很多。最明显的就是删旧数据。以前在一个一千万行的表上DELETE三个月前的数据可能要跑几十分钟还占大量系统资源。分区表直接TRUNCATE或DROP分区秒级完成因为本质上只是删除一个存储段。ALTER TABLE order_flow TRUNCATE PARTITION p202501;这种操作在归档历史数据、清理过期数据时特别好用而且不影响其他分区的数据可用性。分区的维护还需要注意预建分区和索引策略。按时间分区的表建议提前把未来几个月的分区建好避免业务跑到月底时临时加分区引发锁等待。每个分区上是否需要独立索引也要根据查询模式决定。分区表的索引分成全局索引和分区索引两者维护方式和查询效率有差异如果不是特别确定建议在真实数据量下做一次对比测试再决定。6. 技巧五统计信息与并行度配合6.1 别忘了给优化器喂饱统计信息数据库优化器做路径选择时依赖表的统计信息来估算行数和成本。如果统计信息缺失或者严重过期优化器就是瞎猜猜错了执行计划就偏了。很多时候一条SQL昨天还正常今天突然变慢大概率就是数据量变化了但统计信息没跟上。YashanDB上更新统计信息的常用方式是通过ANALYZE语句比如ANALYZE TABLE order_flow COMPUTE STATISTICS;大规模导入数据之后务必跑一次统计信息更新。我记得有一次从文件加载了上百万行数据后没更新统计信息原来的SQL继续走老计划性能明显下降跑了ANALYZE之后执行计划自动切换速度立刻恢复正常。这个动作简单收益却非常高。统计信息更新的频率要看数据变化速度。每天大批量变化的表建议至少一天一次最好是能放到业务低峰期跑避免占用高峰资源。数据基本不变的小表统计一次就可以用很久不用频繁操作。6.2 并行度怎么设才不会被反噬并行执行是分析型查询的利器。YashanDB支持在SQL级别或者表级别设置并行度让一个查询可以拆成多个子任务同时跑充分利用多核CPU。一个典型的用法是加并行提示SELECT /* PARALLEL(o, 4) */ user_id, SUM(amount) FROM order_flow o WHERE create_time TIMESTAMP 2025-01-01 GROUP BY user_id;并行度不是越高越好。并行度过高会产生大量并行进程CPU和内存瞬间被打满反而拖慢整个系统的响应速度。我自己一般先看机器CPU核数分析型查询的并行度设置在核数的四分之一到二分之一之间然后通过实测调优。如果机器是16核先从4开始观察查询耗时和资源占用再决定要不要调高。还有一个容易踩的坑并行度和在线业务是冲突的。OLTP类型的小事务并发能力本来就敏感如果让这些短查询也开并行调度开销甚至会超过查询本身的耗时反而变慢。所以并行只建议用在数据量大的分析型SQL上并且要确认它不会和其他业务抢资源。6.3 并行不是万能药有一个现象值得注意一条SQL全表扫描跑得很慢你给它加并行度它确实会变快但这只是延缓了问题并没有解决“为什么要全表扫描”的根本原因。加并行和建索引的区别就在于此并行是让全表扫描跑得更快索引是让查询根本不扫全表。所以我的优化顺序一般是这样先用执行计划确认访问路径如果确实是全表扫描先考虑索引和分区裁剪如果路径没问题、数据量实在太大才考虑并行。并行是一种资源换时间的策略不要把它当成首选的优化手段。统计信息准确加上合理的并行度分析查询的体验会好很多但两者要配合着用单独依赖任何一个都容易出问题。7. 避坑总结与常见问题速查7.1 五个技巧的适用边界这五个技巧各有用武之地但也有明确的不适用场景。批量操作最适合大数据量导入、清洗、归档类任务。如果业务对实时性要求极高每一次写入都需要立刻被其他事务查询到那就不能攒大批次再提交否则会有可见性延迟。执行计划分析适合所有慢SQL排查但如果是简单的单行点查看计划反而浪费时间不如直接看索引。索引设计适合高频查询加速但不能覆盖所有问题如果一条SQL只是偶尔跑一次全表扫描也能接受的话没必要加索引给自己添负担。分区表适合数据量大且有明确分区键的场景小表强行做分区只会增加复杂度。统计信息和并行度是所有优化工作的底子但统计信息更新也有成本并行度更要注意资源边界。把这几个边界串起来你会发现它们其实是一条决策链遇到慢查询先看执行计划再根据计划判断是索引、分区还是统计信息的问题最后用并行度做兜底加速。顺序不乱出错的概率就小很多。7.2 我最想提醒的几件事踩过这么多坑有几件事我每次都会反复提醒自己。第一不要跳过执行计划直接调参数。很多看起来像“参数问题”的慢SQL归根结底是执行路径错了。参数调了半天没效果回头一看SQL还在全表扫描这种时间浪费完全没有必要。第二加索引之前务必看现有索引。数据库里重复索引很常见建了A(a,b)又建A(a)后者基本是冗余的白白增加写入成本。第三大数据量清理不要一条DELETE删到底。哪怕表有分区如果不能用TRUNCATE分区就要分批删这是保护在线业务的重要手段。第四统计信息更新要形成习惯尤其是批量导入之后这是优化器正确决策的前提。我自己的日常检查清单很简单先问SQL是不是在用小表驱动大表再看有没有不必要的全表扫描然后确认索引有没有被函数或隐式转换废掉最后检查统计信息是否还在有效期。这套顺序用下来绝大多数效率问题都能定位到具体原因剩下的只是改法和验证的时间问题。