【 TiDB 使用环境】测试
【 TiDB 版本】v4.0.15 & v6.5.3
【复现路径】这个问题是来自于“金融监管管理局2月基础软硬件产品缺陷信息表”，收到这个问题时，不清楚具体原因(参考资料)，希望社区能帮助解释下(或者给个链接)。
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】
tidb_max_chunk_size的默认值本身并不会直接导致数据丢失或泄露。它主要影响的是每次从TiDB中获取数据的量。如果设置的值过大，可能会导致单次操作占用过多的内存，从而增加系统压力，但并不会直接导致数据丢失或泄露。
然而，如果在实际应用中，数据的特性与默认值不匹配，例如订单表的数据分散，实际上单个Region上需要访问的数据并不多，那么按照默认配置可能会导致内存使用效率不高，但这也不会直接导致数据丢失或泄露。
总的来说，tidb_max_chunk_size的默认值设置主要是为了优化内存使用和性能，而数据丢失或泄露更多与数据操作逻辑、存储机制等其他因素有关。但在实际应用中，还是需要根据具体的数据特性和业务需求来合理设置这个参数，以确保系统的稳定性和性能。
1 个赞
说他会导致数据丢失和泄漏，我觉得还是牵强了，没有理由啊
tidb_max_chunk_size 本身不会直接导致数据丢失或泄露。它只影响每次查询返回的数据行数，而不会影响数据的完整性。
我觉得可以参考mysql的max_allowed_packet。数据会不会丢失跟这个参数没有关系。
这个表是内部公开，还是公开可查询?
1 个赞
截图上这个描述：“GC瓶颈影响SQL响应时间”，不会是超高并发导致SQL响应时间超过前端应用容忍从而导致用户误认为没数据返回？
这个变量用来设置执行过程中一个 chunk 最大的行数。这个会影响内存的使用，不会影响数据吧
自查发现的，难道是有什么bug吗？
目前我也不清楚在这里是不是有bug的原因，还是说业务把小问题放大。
如果有后续信息，我会在帖子下面继续做说明。感谢各位tidber。
tidb_max_chunk_size的默认值本身并不会直接导致数据丢失或泄露。它主要影响的是每次从TiDB中获取数据的量。它类似于我们格式化硬盘时的簇大小，是一个存储的单位
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。