最简单的就是冒泡啊。
但是你这排序规则怎么定义呢，取前几位字符，汉字转阿拉伯数字，再根据阿拉伯数字排序？

平时做工作记录，面试之前看笔记

关羽张飞都英年早逝，诸葛亮呕心沥血鞠躬尽瘁死而后已，这不仅要努力工作，还要命啊
@johnyu 拿一份钱做一份事，怎么加这么多戏？老板不满意员工，可以选择拿更高的待遇招更好的人。做老板不容易太难，可以选择倒闭或者卖掉公司，给别人打工，做员工只要关心自己的薪资和自己的发展前景。

发信息给对方，对方不回复，这就是沟通能力缺失啊，招进来也不好与团队协作工作的
你是用什么形式发的什么内容的信息？
一般面试流程下来，都是邮件或者电话联系，怎么会不回复呢，不回复怎么进行后续流程，这是真的有点憨。除了面试失败通知，其他的不回复都会影响面试结果吧

我以为我会看到 av 男优,h 文写手之类的

支持#11 老哥

@otakustay 没说不走索引！没说不走索引！都建议分区了，咋能不走索引呢，只是查询出百万条数据，这真扛不住，你内存扛得住，网络都扛不住了，分批取那得多久啊，优化 sql，百万条绝对是 3 秒以内的

@nnnToTnnn
第一、我只是提倡多点包容，不要群嘲，没有意义
第二、还是场景问题，每种解决方案都有适用场景。正确不代表普适性，肯定要考虑场景和成本。这个解决方案，你怎么做，全表数据导出在业务代码中处理，还是为了这一个需求做数据分离？你可以提出你的解决方案，友好讨论
第三、我没有说那个 sql 写得没问题，从表结构设计到 sql 都充满了问题，但是那个业务逻辑确实很简单，只是 sql 写的时候写得有问题，才会使逻辑看起来很复杂，我提出了相应意见，包括你说的“逻辑放到业务层，减少数据库的负担”。但是不代表“尽量把逻辑放到业务层，减少数据库的负担”这句话就有用。
@otakustay 除了内存还有 IO 啊，大数据量即便是分批去取，同样是需要考虑吞吐量的，这个对于简单需求真的得不偿失。我只能说解决方案是解决现实问题的，而且，即便楼上 @nnnToTnnn 老哥跟我如此辩论，我记得他也是看了 sql，提了一些方案的。讲道理，一句“尽量把逻辑放到业务层，减少数据库的负担”除了显得自己像那么回事以外，并没有什么卵用，大家的水平都不差，肯定也是迫于现实的嘛

@l00t 问题很多，估计这老哥也是接盘，以后有得玩了

@marcong95 互联网不等于所有场景，同样也不是一个解决方案就能适用于所有场景。
我并非对前端不太友好，只是我认为在“尽量把逻辑放到业务层，减少数据库的负担”这个问题上前端没有发言权，你们工作环境并没有接触到相关知识，更多来源于他人描述和书本。
而往往前端同学又喜欢用这样“尽量把逻辑放到业务层，减少数据库的负担”这样的回答去答复 sql 的相关问题，你真的了解相应的场景、架构、业务逻辑和解决方案吗？

@blless 我非常同意你的观点，推动架构的改变需要一个过程，以此作为通用的解决方案，对于当事人来说往往是望梅止渴。
PS：企业级应用经常存在面向领导编程和面向客户编程，百万级的数据量就很尴尬，说大不大，说小不小，还就统计这么一个功能专用，为这个上大数据，往往得不到支持和资源。

@l00t 我是出于业务角度去考虑修改的，不好意思，可能确实有失妥当。
目前的查询逻辑是查所有 kpi 信息，那么就可能查出来没有对应人员的 kpi 数据，且不能查出哪些人员的 kpi 数据缺失，
我认为应该是针对所有有效人员去查 kpi。（该业务逻辑确实是我的问题，我还是坚持这种方式更好点，哈哈）

基于以上考虑
account_number AS empNumber 且 GROUP BY ah.account_number 那么 account_number 为空，应该是脏数据了，在 where 中去掉应该没问题，where 中可以加上 ahh.empNumber != 0

最费解的是他这里 account_number 应该就是账户信息了，怎么用 qq 去匹配，如果 qq 对应的就是 account_number 字段，那就直接=，如果有生成逻辑，那就要冗余一个字段吧，用 qq 的 like 匹配肯定会有问题啊。
123456 就会匹配到 1234567 12345678 的数据

@love 对他人的不足适当包容，而非群起嘲讽，不是更友好吗
两秒钟格式化的时间于我而言，并不费力，为什么不和善一点呢。“请尽量让自己的回复能够对别人有帮助”，我认为忽略不足，回以答案，更有帮助

@linkedsh1005 前面还是调侃，后面部分回复里已经出现了这种自以为是的粗暴式解决方案了。