yingyunzhizi的博客

第二点因为树高度一致的情况下，B+tree树进行关键字段查询时候路径是一样，查询时间就是一样的，这种数据结构就很稳定，不像Btree树一样还要考虑前序后序这些东西，查询速度可能不一样的。(说一个，where和having区别where是在查询结果之前就过滤了，having是查询结果之后才过滤，肯定where的性能好一些，平时我们也是用这个)1、先简单说2者BTree树结构是查询树，所有结点都存储数据，key-data，B+tree树是最下层叶子结点才存储数据，上面都存储索引列，......

2、通过查询sql模板，发现那段有大调用量的就是有个联合sql，select*fromajoinbona.issuerId=b.issuerId,2个表都是小表，各自1000条记录，然后使用这个表的接口平时调用量也很少，高峰也就300条，但是那天因为64万条消息给用户，发生cpu问题前2分钟调用量超过100倍，有30万接口进来，2分钟内这么多，并发量很高了。4、idin子查询，子查询返回是false，true是否存在这种，你使用idexsit子查询即可，否则也是索引失效。......

如果是写>读的，要用悲观锁，否则所有读的操作都会被阻塞，等写的操作执行完成了才有机会去读，所有读的程序都要阻塞挂在外面。比如线程1,2都需要a，b锁，线程1获得了a锁，线程2获得了b锁，都无法让对象继续获取锁。乐观锁度数据操作是乐观的态度，认为不会修改数据，所以性能稍微好点，他不加锁的，但是在写操作时候会先读，看是否被修改过。悲观锁对数据操作是悲观的态度，认为别的线程会修改数据，所以每次操作都加锁，操作完成才释放锁。Synchronized，是java关键字，用来锁代码块和方法，本质是悲观锁。...

经常使用mysql，然后就有一些sql的优化，可以帮忙性能的提升1、条件where，group by ，order by后面尽量使用索引，否则是全表扫描。2、模糊查询like不能都用%包围，最好就在后面使用，否则会让索引失效。错误：where id like %xxx%;正确：where id like xxx%;3、使用in范围查询的地方，尽量改成between。错误：where id in (2,3);正确：where id between 2 and 3;4、in使用子