性能与稳定
-
关于性能
默认情况下AnyLine的性能是比较低的，这主要是指的DataSet/DataRow的性能
在分页情况下每页几十行数据没什么影响，但在一次性处理几十上百万行数据时会非常耗时。
原因是DataSet/DataRow要适配各种复杂的检索，如：
忽略大小写、驼峰与分隔符转换、正则表达式、排序、维度转换、截取、去重、方差、偏差、交集合集差集、分组、忽略大小写对比、行列转换、类SQL过滤筛选(like,eq,in,less,between...)、JSON、XML格式转换等
在每一次get/set操作中都有可能涉及这些情况，详细请点开DataRow的put/get方法看一下
在大多数情况下使用会比较方便，如
DataRow.get("user_id")/get("userId")/get("userID")都能获取到期望结果;
DataSet.get("NAME","张%");可以获取NAME以张开头的行
当然智能也意味着运行低效
通常在处理大数据时需要设置DataRow的KeyCases为SRC模式，或者返回Entity/Map格式的数据
把DataSet set = service.querys()换成List<Map> list = service.maps()
也就是让系统精确的按人为指定的模式去运行，编码阶段能确定的事不要交给运行时处理。
另外注意如果数据量比较大，不要用maps(表,PageNavi) 因为每次都会查总行数，除非设置PageNavi.setLazy(毫秒)表示多长时间内只查询一次总行数
查询
如果还需要再快需要启动流式查询方式，这样会保持一个较长的连接，并返回一个迭代器，而不是把数据一次性读取内存中。参考【流式查询】
除此之外，性能主要取决于数据库设计与应用。
插入
插入大批量数据时，不要用save,因为save会逐行检测是insert还是update
可以service.insert(int batch, String table, Object data) 这里的batch>1时会调用jdbc的批量操作 data可以是一个List<Map>
也可以手工拆分成多个List跟jdbc批量效果类似,都是多条数据集中到一次命令中
更新、删除
也可以通过batch触发批量执行(不过这并没什么适用的场景,实际测试也并没有快多少)
如果还是不够快，就是因为anyline在构造SQL时会执行各种检测耗时了，需要更快的执行可以构造好SQL后调用execute(int batch, String sql, List<Object> values)或execute(int batch, String sql, List<List<Object>> values)
需要注意的是，批量执行需要保持每行SQL的参数一致，并且批量方执行时并不会触发全部的监听和拦截事件，也不完整统计影响行数
-
关于稳定性
比较让人失望的是稳定性也很难保证，DML方面比较稳定已经很常时间没有新需求了，但DDL方面只实现了常用部分。
由于每天都有需的需求提出，所以代码每天都会更新，但测试用例有点跟不上节奏。
值得庆幸的是：每天都有众多的近一线人员在测试验证，特别是谁提出的需求，更会测到自己满意为止。很难有BUG能长期逍遥法外。
同时我们的响应速度也会非常快，只要不是涉及到结构变更的问题一般不会留到第二天。
如果遇到有需要但没有实现的、不够简捷的、方法名参数名有点啰嗦的请联系群客服，我们会立即补齐。
别外需要注意有些DDL之间是相互冲突的，应该同时执行还是先后执行要根据实际情况。
