提交sql的注意事项

README.md

@@ -63,6 +63,7 @@
 | 021 |分布式事物解决方案（未更新） |[解决思路](/docs/code-solve.md)   |
 | 022 |mysql主从复制思路及实操（未更新代码） |[解决思路](/docs/mysql-master-slave.md)   |
 | 023 |如何进行分库分表 |[解决思路](/docs/mysql-master-slave.md)   |
+| 024 |秒杀类似场景sql的写法注意事项有哪些？|[解决思路](/docs/mysql-master-slave.md)   |
 
 #### [分布式系统发展历程（已更新）](/docs/fenbushi.md)
 #### [分布式系统](/docs/redis-code.md)
@@ -73,7 +74,7 @@
 #### [通信mq-Kafka--未更新](/docs/redis-code.md)
 #### [微服务框架--未更新](/docs/redis-code.md)
 #### [JVM内存解析与性能调优--未更新](/docs/redis-code.md)
-#### [面试专题（最后更新）--未更新](/docs/redis-code.md)
+#### [面试专题（最后更新）--未更新](/docs/code-solve.md)
 
 
 

docs/code-solve.md

@@ -111,13 +111,31 @@
     值比较，如果无变化说明这个期间没有人获取或者操作这个redis锁，则可以重新获取
     V4---->>采用成熟的框架redisson,封装好的方法则可以直接处理，但是waittime记住要这只为0
 #### [服务降级--服务熔断(过载保护)）]()
-    自动降级： 超时.失败次数,故障,限流<br>
-    人工降级：秒杀，双11<br>
+    自动降级： 超时.失败次数,故障,限流
+    人工降级：秒杀，双11
     
-    9.所有秒杀相关的接口比如：秒杀，获取秒杀地址，获取秒杀结果，获取秒杀验证码都需要加上<br>
+    9.所有秒杀相关的接口比如：秒杀，获取秒杀地址，获取秒杀结果，获取秒杀验证码都需要加上
     秒杀是否开始结束的判断
 #### [RPC事务补偿]()
     当集中式进行服务化RPC演进成分布式的时候，事务则成为了进行分布式的一个痛点，本项目的做法为：
     1.进行流程初始化，当分别调用不用服务化接口的时候，成功则进行流程，失败则返回并进行状态更新
     将订单状态变为回滚
     2.使用定时任务不断的进行处理rollback的订单进行回滚
+    
+#### [秒杀类似场景sql的写法注意事项]()
+    1.在秒杀一类的场景里面，因为数据量亿万级所有即使有的有缓存有的时候也是扛不住的，不可避免的透穿到DB
+     所有在写一些sql的时候就要注意：
+     1.一定要避免全表扫描，如果扫一张大表的数据就会造成慢查询，导致数据的连接池直接塞满,导致事故
+     首先考虑在where和order by 设计的列上建立索引
+     例如： 1. where 子句中对字段进行 null 值判断 . 
+           2. 应尽量避免在 where 子句中使用!=或<>操作符 
+           3. 应尽量避免在 where 子句中使用 or 来连接条件
+           4. in 和 not in 也要慎用，否则会导致全表扫描
+           5. select id from t where name like '%abc%' 或者
+           6 .select id from t where name like '%abc' 或者
+           7 . 若要提高效率，可以考虑全文检索。 
+           8 .而select id from t where name like 'abc%' 才用到索引 慢查询一般在测试环境不容易复现
+           9 .应尽量避免在 where 子句中对字段进行表达式操作 where num/2  num=100*2
+     2.合理的使用索引  索引并不是越多越好，使用不当会造成性能开销
+     3.尽量避免大事务操作，提高系统并发能力
+     4.尽量避免象客户端返回大量数据，如果返回则要考虑是否需求合理，实在不得已则需要在设计一波了！！！！！