为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】v4.0.9
【问题描述】请问分区表的单个分区内，多少行记录有个大概的指标范围吗？如果分区内记录比较少，分区又比较多，sql执行是不是性能会有影响？
场景如下：
一张表，我按日期做分区键，每日数据量有3000w，查询的时候经常查日期范围包括1个月的；这种分区方式是否合理？
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
- 每个分区的数据量根据业务来设计，每天 3000 万数据是均匀分布到各时段还是某个时段集中写入呢，这里需要考虑写入性能，比如热点和可扩展性问题
- 历史分区如果有定期清理可以考虑 range 分区，单表不建议分区数太多会有一些性能问题，tidb 目前支持的上限是 1024 个分区
- 查询范围涉及到跨分区，目前 4.0 版本在分区裁剪和支持 index join方面有待完善的地方，可以先对性能做下压测，部分优化会在 5.0 版本实现（https://github.com/pingcap/tidb/projects/52）
1.3000万是比较均匀写入的，高峰也大概不超过2000r/s；
2.我们只保留1年的数据，理论上就只有366个分区
3.会跨分区，可能会查3个月的数据，这就会跨90个分区；如果我把分区粒度设到月上反而好点？因为目前已经在生产上了，测试环境短期没法造出这么多的数据；
另外，我们写不是很敏感；我们这个库主要用来查
一年三百多分区还好，查询性能需要看具体 SQL，可以先灰度部分读流量，看下执行计划以及有没有待优化的 slow query。
有慢sql；一条sql夸分区查1个月的,Query_time ：10s，其中Compile_time有6s多
能否发一下 slow query 日志和表结构信息
非常感谢
compile 高是偶尔出现还是稳定复现，如果能复现，可以执行下 explain + SQL 和 trace + SQL 看看结果
不是必现的，再看这个：
select tidb_decode 的历史执行计划中下推到 coprocessor 的 HashAgg 耗时不均衡，最大 13.488316714s，但是处理的 max_proc_keys 并不多
cop_task: {num: 110, max: 13.488316714s, min: 4.635156ms, avg: 143.054439ms, p95: 85.126907ms, max_proc_keys: 7, p95_proc_keys: 5, tot_proc: 212ms, tot_wait: 688ms, rpc_num: 112, rpc_time: 15.671216653s, copr_cache_hit_ratio: 0.00}
可以看下 2021-02-28T09:58:27 这个时间的监控面板 Unified Read Pool，Coprocessor Overview，Coprocessor Detail，确认有没有一些资源上的瓶颈
Compile 高也可以看下 2021-02-28T09:00:34 的 tidb 监控，确认对应 compile duration 监控面板中升高的时间点，检查这个时间前后 tidb server 的 cpu util，load 等负载情况