为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：V4.0.4
- 【问题描述】：在使用表分区，加索引，开辟列存等优化方式之后，基本上所有的分析查询都可以毫秒级返回。但是在进行首次查询时，速度很慢。这个怎么优化呢？
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出打印结果，请务必全选并复制粘贴上传。
首次查询需要把信息从sst文件读取到内存中，之后查询走内存会快，这个感觉没有什么好的方法。 除非你的内存足够大，能够把所有读取到的内容缓存在内存中可能才行。
怎么可以提高分区表加载SST的速度呀，我这个按周分区的表，其实每周就几十万数据。
100多万的单表查询，比分区表第一次查询要快很多。
单表快是因为已经存在内存中了吧。还是说，分区第一次加载比单表第一次加载慢？
单表和分区一样，也是隔了很久才查询的。
麻烦上传下这两个sql的执行计划，explain analyze sql ，多谢。
着两个SQL不一样吧，上面还要进行sum聚合运算，下面只是count计算一下。
但是执行计划中，select阶段的速度也是没分区表比分区表快呀。
麻烦反馈一个相同的select 执行计划直观的看下，多谢。
前两个是不同分区的对比，都是首次查询；
第三个是针对第二个的再次查询；
后两个是非分区表首次查询和再次查询；
分区表首次查询速度不是很好，和非分区表差不了多少，但是再次查询速度会很快。
SST的首次加载，在分区表上的表现并没有比非分区表好。
您好，请问慢查询日志里有相关 sql 的信息吗，执行时间大于 1s 的
怀疑是 region cache 的问题
每个表都是对应到 kv range 的，再按数据量达到比如 96M 把 kv range 切分成一个个 region
region 信息在 pd 里面存着，然后 tidb 会缓存 region 信息方便定位查询请求到 region 的变换
缓存是有上限和过期时间的，如果 15min 没有访问过，region cache 就失效了
分区表涉及的 region 很多，长期不使用可能就 region cache 失效
然后出现你说的现象，首次很慢，后面快很多
首次可能去访问 pd 取 region cache 去了
我不知道 4.0.4 版本里面带没带这个 PR
https://github.com/pingcap/tidb/pull/18337
如果带了的话，可以用 trace format=‘row’ 验证一下执行的时候是不是取 region cache 了
另外请执行一下 show variables like "%config%"; 确认一下 copr-cache 是否打开。如果打开，应该是这个原因导致后面的查询很快，和 sst 没有关系。
很大可能是因为 copr-cache 被打开，具体原因是后面的 explain analyze 结果中，cop 部分出现了 min:0s 这样的字段，表示某个 tikv 查询任务只执行了 0s，这个多半是因为之前结果被 tidb cache 住了。
copr-cache没有打开
| tidb_config | {
“host”: “0.0.0.0”,
“advertise-address”: “172.16.117.177”,
“port”: 4000,
“cors”: “”,
“store”: “tikv”,
“path”: “172.16.117.177:2379,172.16.116.153:2379,172.16.117.77:2379”,
“socket”: “”,
“lease”: “45s”,
“run-ddl”: true,
“split-table”: true,
“token-limit”: 1000,
“oom-use-tmp-storage”: true,
“tmp-storage-path”: “/tmp/1001_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage”,
“oom-action”: “log”,
“mem-quota-query”: 1073741824,
“tmp-storage-quota”: -1,
“enable-streaming”: false,
“enable-batch-dml”: false,
“lower-case-table-names”: 2,
“server-version”: “”,
“log”: {
“level”: “info”,
“format”: “text”,
“disable-timestamp”: null,
“enable-timestamp”: null,
“disable-error-stack”: null,
“enable-error-stack”: null,
“file”: {
“filename”: “/data/soft/tidb/deploy/tidb/logs/tidb.log”,
“max-size”: 300,
“max-days”: 0,
“max-backups”: 0
},
“enable-slow-log”: true,
“slow-query-file”: “log/tidb_slow_query.log”,
“slow-threshold”: 300,
“expensive-threshold”: 10000,
“query-log-max-len”: 4096,
“record-plan-in-slow-log”: 1
},
“security”: {
“skip-grant-table”: false,
“ssl-ca”: “”,
“ssl-cert”: “”,
“ssl-key”: “”,
“require-secure-transport”: false,
“cluster-ssl-ca”: “”,
“cluster-ssl-cert”: “”,
“cluster-ssl-key”: “”,
“cluster-verify-cn”: null
},
“status”: {
“status-host”: “0.0.0.0”,
“metrics-addr”: “”,
“status-port”: 10080,
“metrics-interval”: 15,
“report-status”: true,
“record-db-qps”: false
},
“performance”: {
“max-procs”: 0,
“max-memory”: 0,
“stats-lease”: “3s”,
“stmt-count-limit”: 5000,
“feedback-probability”: 0.05,
“query-feedback-limit”: 1024,
“pseudo-estimate-ratio”: 0.8,
“force-priority”: “NO_PRIORITY”,
“bind-info-lease”: “3s”,
“txn-total-size-limit”: 10737418240,
“tcp-keep-alive”: true,
“cross-join”: true,
“run-auto-analyze”: true,
“agg-push-down-join”: false,
“committer-concurrency”: 16,
“max-txn-ttl”: 600000
},
“prepared-plan-cache”: {
“enabled”: false,
“capacity”: 100,
“memory-guard-ratio”: 0.1
},
“opentracing”: {
“enable”: false,
“rpc-metrics”: false,
“sampler”: {
“type”: “const”,
“param”: 1,
“sampling-server-url”: “”,
“max-operations”: 0,
“sampling-refresh-interval”: 0
},
“reporter”: {
“queue-size”: 0,
“buffer-flush-interval”: 0,
“log-spans”: false,
“local-agent-host-port”: “”
}
},
“proxy-protocol”: {
“networks”: “”,
“header-timeout”: 5
},
“tikv-client”: {
“grpc-connection-count”: 4,
“grpc-keepalive-time”: 10,
“grpc-keepalive-timeout”: 3,
“commit-timeout”: “41s”,
“max-batch-size”: 128,
“overload-threshold”: 200,
“max-batch-wait-time”: 0,
“batch-wait-size”: 8,
“enable-chunk-rpc”: true,
“region-cache-ttl”: 600,
“store-limit”: 0,
“store-liveness-timeout”: “5s”,
“copr-cache”: {
“enable”: false,
“capacity-mb”: 1000,
“admission-max-result-mb”: 10,
“admission-min-process-ms”: 5
}
},
“binlog”: {
“enable”: false,
“ignore-error”: true,
“write-timeout”: “15s”,
“binlog-socket”: “”,
“strategy”: “range”
},
“compatible-kill-query”: false,
“plugin”: {
“dir”: “”,
“load”: “”
},
“pessimistic-txn”: {
“enable”: true,
“max-retry-count”: 256
},
“check-mb4-value-in-utf8”: true,
“max-index-length”: 12288,
“alter-primary-key”: false,
“treat-old-version-utf8-as-utf8mb4”: true,
“enable-table-lock”: false,
“delay-clean-table-lock”: 0,
“split-region-max-num”: 1000,
“stmt-summary”: {
“enable”: true,
“enable-internal-query”: false,
“max-stmt-count”: 200,
“max-sql-length”: 4096,
“refresh-interval”: 1800,
“history-size”: 24
},
“repair-mode”: false,
“repair-table-list”: [],
“isolation-read”: {
“engines”: [
“tikv”,
“tiflash”,
“tidb”
]
},
“max-server-connections”: 0,
“new_collations_enabled_on_first_bootstrap”: false,
“experimental”: {
“allow-expression-index”: false
},
“enable-collect-execution-info”: true,
“skip-register-to-dashboard”: false,
“enable-telemetry”: true
} |
讲道理的话，分区表重新进行region cache要比非分区表快得多才对，毕竟分区表更容易命中region以及加载更少的region数据
您好，请你查一下 tikv 的日志吧，对于这种大于 1s 的 query，tikv 会输出一条慢日志记录是否从磁盘读数据，如果确认是首次加载 sst 的问题，那么这个第一次查询速度慢目前是很难改善的。
