哦，还想起来一个场景，对于一些数字形字符是否有隐式转换为数字，造成对数字可以用上索引之类的。可能在不同的接入客户端模式上也有不同。对应的 preparestatement 或者 orm 框架上，对应的既能数字、也能文字的字段类型，是否正确绑定，用上了索引。

@crasa 还是看下执行计划吧，有分页也会再被 fetchsize 最终再限制

可能是终端和程序调用时上 fetch 条数的默认设定不同导致，终端默认 fetch first 50 或窗口大小可显示条数，导致执行计划和实际开销都优于，程序默认调用全量返回数据的执行计划和实际开销

可以尝试通过程序侧调用执行计划获取一下，比对一下终端都执行计划

最终程序执行上要考虑耗时功能优化翻页等等

如果上报指的是上报监控类信息的话，为啥要选择长连接方案？

业界标准上对于上报非关键信息的话，短连接 UDP 已经是标准做法了吧。突破现有标准做法的是有什么特殊需求目的、和环境特异性么？

@mengzhuo 上传 shell 又不会被执行的……只会被 sed 处理、按 loader 工具按照预定的分割规则进行分隔符切割/定长分割处理后由工具入库，工具也不会用 SQL 引擎解析其中文字。读帖首先看题干看题干看题干…

这么多信息，S 在其中……感觉是出题的干扰选择项嘛

A 和 B 的通信是否安全，现在就归结于拿到了 K 的 C 怎么使用 K 了

如假设：
1 、B 没有告诉 C ，有 S 的存在，C 通过自身能力、也无法获知 C 的存在与对应调用方法，粗且可以认为 A-B 是安全。
2 、B 告诉了 C ，有 S 的存在，但一般来说，S 对于 B 的交互注册，有名为 KS 的 key 存在，对 KS 尽管 B 喝醉了、B 没有 C ，那么粗且可以认为 A-B 安全

另外，以上假设是从 B 对 C 的情况已经透明可知的情况，如果对于 B 并没有把喝醉这件事情记起来、更没有告诉 A 。那么从 A 视角来看，还有 A 认为 A-B 间是否安全的问题。

从严格的安全角度来看，既然 K 已经泄露了，第一时间更换 K ，是比做上述各种假设更为安全的选择。

jvm 总体不要设过容器一半。各种 gc 相关参数打开、oom 时就能产生 heapdump ，拿出来分析内存溢出/泄露对象

还有：@imyasON

不要 不要 不要 随便随便就设置等同的 xms 和 xmx 。当堆内用量情况很平稳没有升代、长时间不需要 fullgc ，没有 fullgc 就有不能触发挂载在 finalizer 上的资源回收，可能导致包括堆外溢出等各种各样的资源耗尽问题。在确认没有堆外资源、没有 finalizer 依赖等等情况下，已经做过深度优化的基础上再考虑 xms=xmx 的设定。

Windows 默认输入法 bug ，要选择使用兼容性老版本

健康又卫生不得不尝

https://www.zhihu.com/question/389219452

洋垃圾准系统一套 200~300 ；+30 、40 一张千兆网卡
足够了，真讲划算比混这个再说吧

@mengzhuo 这正是用各类 loader 工具而不用自己代码程序的好处，各类 loader 工具和程序 sql 的差异了解下？

@hzjseasea 因为稍微正经点的数据库，都会有在 shell 下能够直接用起来的，配套文本导入工具/命令行功能。Oracle 的 sqlldr ； MySQL 的 LOAD DATA ； PG 的 COPY FROM 等等。原生直接对接数据库，速度快，不用再研发。数据库运维掌握这些工具是必备技能，出了啥问题也是运维和数据库公司支持方面搞定。（其实多少也是为了研发可以推点活到运维吧）

@jptx 恩，这就是比老老实实手动编码的思路，更老老实实的思路了。确实有道理，展示层进出的时候就弄掉，中间一路干净也是是正道。

能发送返回 http 就是浏览器

能解析 html 就是浏览器

能 render 页面就是浏览器

能执行 js 等动态脚本才是浏览器

来画个九宫格？

@NessajCN 后端要交出这块数据处理调用给到二次开发手里的，既然是二次开发，就要选择最没有依赖、人人都能用起来的语言环境=>我选择 shell 作为首先要支持的语言环境、或者由二次开发选择通过 shell 再调用他们自己研发的语言代码的入口。

@NessajCN 还有略的部分，看来这个要处理的内容还是会比较多的。利用 linux 命令和现有 sqlloader 工具就能实现的，差不多几行脚本和工具调用命令，就能实现的话；个人还是感觉不大会有二次开发人员，去首选自己开发这些代码了。何况相比 shell ，还有多个 nodejs 环境基础依赖。nodejs 较 shell 来说，不是通用入口的优选。

@NessajCN 求教了，如果我要用 fs 做一个：

1 、显示类似 sed 去掉数据文件行末和文末空格空行；

2 、在完成步骤 1 后，实现类似 sqlloader 工具，将处理后文件导入指定数据库。

这个应该如何做到呢？

@NessajCN 大概确实是我需求部分表达有问题了。服务器端调用 sed 、sqploader 、或其他自有工具等形式，对数据的文本清洗处理等后再加载。其中用 shell 作者为先后处理/加载的过程的总入口，我理解是最通用的一种文件上传处理框架中，需支持的入口模式了。我不能理解，fs 能够作为数据文件清洗/处理/加载的总入口吗？

@mengzhuo 可能是我表达不清？ txt 文件上传后，服务器端自动触发开发编写的 shell ，去进行对 txt 文件的数据处理。不是 webshell ，我不觉得这个有什么安全问题。

@jifengg 做的是框架性通用性功能。如果要求服务器统一编码会限制通用性功能的使用范围。设计思路上是能减少一个用户要求，就减少一个用户环境要求。

而且，全流程 utf-8 会要求，不单单是服务器了。要求前端页面等也得 utf-8 、才能客户端浏览器以 utf-8 处理，这种传染形式，就更不利于框架性功能的推广了。