tongjiann

感谢大家的回复，最终根据 17L 的建议进行了修改

@justyeh #37 我描述的不够准确，首先，肯定不可能在每个业务类中修改代码实现这个功能，最起码也要抽一层出来，尽可能减少与业务的关联性，保证后续新增业务表也不需要修改这里的代码。我最终的实现方案是参照 17L 的方式，写一个拦截器，统一在 SQL 执行前进行拦截，然后判断，如果需要就注入 SQL

@boqiqita #30 目前已有总数据量千万吧，月度数据增量大概百万，QPS 不高，可能就月底用一下？属于绩效系统，从外部取数，然后算出绩效，面向的对象是主要还是绩效专员

@andy2415 #19 谢谢，还贴了代码

@Morii #18 最终的数据要进行后续的操作，如前端展示，那这个时候需要的不只是数据条数了，count 还不够吧

@leejinhong #9 这个需求是针对系统的需求，和业务无关，最终实现肯定是在一个 ORM 层进行实现，并不是在每个业务实现类中进行操作

@dong568789 #5 这个 idea 很好，和我的第一种想法类似，不过你的可能更加完善。我验证一下这个方法在我们代码中的可行性

@paopjian #7 是的，从代码设计上来说没问题。但是我们目前的系统为了偷懒，允许前端通过构建类似于 SQL 查询条件的方式，直接请求通用接口查询数据库中的数据，可以直接跳过对应字段的校验。但是已经是一坨了，只能往上面再来一坨了

@Musong #2 你说的没问题，部分请求中存在这个参数，确实可以在查询之前进行拦截。但是吧，有部分情况是，比如和描述中一样，select * from table a where id = 'xxx'。这个时候我并不知道查询出来的数据的 period 是啥。还得查出在之后再进行校验看看是不是合法数据。不过这个方法可行，确实可以加两层，前面先过滤掉一批，这样可以适当的减轻数据库的压力