最近在牛客网上看到一个帖子，真是刷新了我对“职场套路”的认知。
事情是这样的：有家公司为了调整业务，把一个月薪一万五和一个月薪三万的裁掉了，并且把他们的工作都交给了该网友，该网友提出涨薪变成十恶不赦了。
三个人的活让一个人干，这谁能抗的住，如果真想让一个人干涨点工资也很正常，但是没通过，所有网友都劝他赶紧跑。
有网友干脆利落地建议：“直接跑路！”这话说得不无道理，在这种“多干活、没涨薪”的情况下，留下来简直就是对自己不负责任嘛。
另一位网友提了个更现实的建议：“给多少钱干多少活，同时做好找下家的准备。”这句话真是切中要害。
老板不愿意加薪，那咱就按工资干活呗，谁还不是个打工人呢？
还有网友建议“拖字诀”：分外的慢慢做呗。
我觉得，在职场上，要保持良好的心态。面对不合理的待遇，冷静思考是第一步。别被公司的“奇葩操作”扰乱了心情。
工作是为了更好的生活，生活都一团糟还工作个p啊。遇到这事，我们首先得想想如何理性应对，不能被情绪左右。
如果公司不愿意调薪，那还是得提前谋出路。提高个人技能，做好职业规划，给自己多留几条出路。这样即便不干了，也不至于被打个措手不及。此地不留爷自有留爷处，即使大环境再糟糕，只要自己能力过硬还是有出路的。
以下是今天的SQL干货
SQL优化一般步骤
1、通过慢查日志等定位那些执行效率较低的SQL语句
2、explain 分析SQL的执行计划
需要重点关注type、rows、filtered、extra。
type由上至下，效率越来越高
- ALL 全表扫描
- index 索引全扫描
- range 索引范围扫描，常用语<,<=,>=,between,in等操作
- ref 使用非唯一索引扫描或唯一索引前缀扫描，返回单条记录，常出现在关联查询中
- eq_ref 类似ref，区别在于使用的是唯一索引，使用主键的关联查询
- const/system 单条记录，系统会把匹配行中的其他列作为常数处理，如主键或唯一索引查询
- null MySQL不访问任何表或索引，直接返回结果
虽然上至下，效率越来越高，但是根据cost模型，假设有两个索引idx1(a, b, c),idx2(a, c)，SQL为select * from t where a = 1 and b in (1, 2) order by c;如果走idx1，那么是type为range，如果走idx2，那么type是ref；当需要扫描的行数，使用idx2大约是idx1的5倍以上时，会用idx1，否则会用idx2
Extra
- Using filesort：MySQL需要额外的一次传递，以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序，并按排序顺序检索行。
- Using temporary：使用了临时表保存中间结果，性能特别差，需要重点优化
- Using index：表示相应的 select 操作中使用了覆盖索引（Coveing Index）,避免访问了表的数据行，效率不错！如果同时出现 using where，意味着无法直接通过索引查找来查询到符合条件的数据。
- Using index condition：MySQL5.6之后新增的ICP，using index condtion就是使用了ICP（索引下推），在存储引擎层进行数据过滤，而不是在服务层过滤，利用索引现有的数据减少回表的数据。
3、show profile 分析
了解SQL执行的线程的状态及消耗的时间。
默认是关闭的，开启语句“set profiling = 1;”
代码语言：javascript复制SHOW PROFILES ;
SHOW PROFILE FOR QUERY #{id};
4、trace
trace分析优化器如何选择执行计划，通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。
代码语言：javascript复制set optimizer_trace="enabled=on";
set optimizer_trace_max_mem_size=1000000;
select * from information_schema.optimizer_trace;
5、确定问题并采用相应的措施
- 优化索引
- 优化SQL语句：修改SQL、IN 查询分段、时间查询分段、基于上一次数据过滤
- 改用其他实现方式：ES、数仓等
- 数据碎片处理
