我有一个Mysql表，目前拥有大约1000万条记录 . 记录由另一个批处理应用程序继续插入并继续增长 . 在前端，用户可以根据不同的标准搜索该表上的数据 . 我正在使用查询DSL和JPA存储库来创建动态查询并从表中获取数据 . 但是分页查询的性能非常慢 . 我尝试过索引，InnoDB相关的调整，HikariCP的会话管理和ehcahe解决方案，但仍然需要大约100秒来获取数据 . 实体也是简单的POJO，与其他实体无关 .
实现此方案的最佳方法/技术/框架是什么？
在这个大小的表中，动态查询是一个非常非常糟糕的想法，您需要真正控制对表的访问并不惜一切代价避免表扫描 .
最终，这听起来像一个数据仓库解决方案，而数据被ETL转换为类似报表的格式而不是原始事务数据 . 即便如此，您仍然需要定义所需的访问模式，并设计DWH以支持它 .
如果您确定原始数据仍然是最佳格式，则另一种方法是定义可以查询的支持元数据表，以便更快地减少返回的行数 .
如果你能找到一些逻辑上将数据分成块的方法，也可以看一下聚类数据 . 但是，当您说动态查询时，这可能是不可能的 .
我的建议是创建一个专用缓存，Web应用程序应该查询缓存而不是数据库 . 如果主表的ETL批处理定义了一段时间，则可以通过触发从主表到缓存的加载来保持缓存热 . 这可以像Ignite或Infinispan那样在内存缓存中使用 . 但是，这不是一个可持续的解决方案，最终您需要限制用户仅在可管理的日期范围内查看数据，并且必须通过平面文件生成的报告丢弃或发送旧数据 . 并非巨大数据集的整个历史记录可以在UI中提供给用户 .
在决定 生产环境 中的分区策略之前，您还可以尝试使用数据虚拟化工具来确定用户更满意的内容 .
2 回答
在这个大小的表中，动态查询是一个非常非常糟糕的想法，您需要真正控制对表的访问并不惜一切代价避免表扫描 .
最终，这听起来像一个数据仓库解决方案，而数据被ETL转换为类似报表的格式而不是原始事务数据 . 即便如此，您仍然需要定义所需的访问模式，并设计DWH以支持它 .
如果您确定原始数据仍然是最佳格式，则另一种方法是定义可以查询的支持元数据表，以便更快地减少返回的行数 .
如果你能找到一些逻辑上将数据分成块的方法，也可以看一下聚类数据 . 但是，当您说动态查询时，这可能是不可能的 .
我的建议是创建一个专用缓存，Web应用程序应该查询缓存而不是数据库 . 如果主表的ETL批处理定义了一段时间，则可以通过触发从主表到缓存的加载来保持缓存热 . 这可以像Ignite或Infinispan那样在内存缓存中使用 . 但是，这不是一个可持续的解决方案，最终您需要限制用户仅在可管理的日期范围内查看数据，并且必须通过平面文件生成的报告丢弃或发送旧数据 . 并非巨大数据集的整个历史记录可以在UI中提供给用户 .
在决定 生产环境 中的分区策略之前，您还可以尝试使用数据虚拟化工具来确定用户更满意的内容 .