nokiaisacat的专栏

对于一般的依赖于关系型数据库的项目来说，数据库的设计决定了软件项目的复杂度，以及性能等方面。最近很多项目的经验都是感觉被数据库的设计给坑了，这里面有自己设计的，也有别人设计的。总之数据库的设计非常重要，所以不得不对它有所思考。说起数据库设计，首先不免想到三大范式，然而三大范式并不完全涵盖数据库设计的各个方面。三大范式只说了一件事，就是表的列要有充分的原子性，要够单纯。第一范式说列必须是原子的；

最近在对一个已经运行了4年的老项目进行性能优化，这是一个app，我主要还是从后台优化。这个项目后台提供的API并不多，只有十几个，但是性能非常差。有些API连每分钟2000的request都扛不住，虽然后台的并发node已经增加到8个。一看代码就知道为什么了，原来这些API都需要返回很多的数据，而且是级联的数据，就像你要获得一个“军”的数据，“军”下面又有“师”，然后是旅团营连排，这样的树状结构，

今天优化一个存储过程，这是一个关于查询的存储过程，因为需要查询的数据比较多，所以写了存储过程，比较耗时的是1. 需要join很多表，2.需要进行多次排序计算排名，3.需要进行计算得到一些平均值，4.有个复杂的查询需要循环处理。由于做其他接口的时候意见将排名信息预先计算并保存所以第二步算是省下来了。这个存储过程很慢，开始的时候想到可能是循环的原因，用游标做了循环。想了很久终于想到了如何用join

mysql参考文档中关于query cache的配置的说明：http://dev.mysql.com/doc/refman/5.7/en/query-cache-configuration.html与查询缓存相关的参数一共有3个，第一个就是have_query_cache，如果只是看到这个值设置为YES就觉得查询缓存开启了就大错特错了。默认情况下这个值一直都是YES。另外两

explain 命令可以很清晰的展现sql 语句的执行计划，对于优化SQL语句很有帮助。在我看来执行计划中最有用的两列莫过于type和rows。rows很好理解就是这个查询遍历的行数，当然是越少越好了。type列就是指join type，也就是本文要尝试阐述的。mysql的使用文档中有对join type的解释：http://dev.mysql.com/doc/refman/5.7/en/

最近遇到一个需要在in里面写limit子查询的情况，然后执行SQL的时候就遇到这个错误：Error Code: 1235. This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'，比如查询是：select * from owner_ship where owner_id in (selec

最近写了一个查询语句，为了做这个查询创建了一些view，最终的view中包含了另外两个view。这个SQL的查询要传入一个条件语句，最后发现这个SQL语句会随着数据量的增加而越来越耗时。即使为所有可以创建索引的地方都已经创建了索引也没有用。用explain解释之后发现这个语句在执行其中的子查询时是查询了全表的。也就是说条件语句的传入不会影响到子查询，子查询并不会去使用索引。直接使用普通的SQL

如果项目本身就是分析性大于事务性的，那一开始的设计就会把数据库设计成分析性的。但是如果一开始是设计成事务性的，我们必然也有需求做一些分析性的工作－单纯事务性的项目比较少。那这种时候我们就需要把这种事务性的表向分析性做一些转化。view可以很好的起到这个作用，既不用重新建表，又可以建立新的表结构。view都是建来做查询的，所以view的创建一定要考虑很好的满足分析性。 语文数学尼玛10020铁锤10099一般我们设计关系型数据库的表会把这种关系设计成三张表，学生表，课

最近公司的一个系统频繁的发生内存泄露，把server上的dump文件下载下来打开却是损坏的。用Jconsle监控server发现，线程的数量和内存的使用率都在不断上升。服务器重启后还好，运行一天之后就会发现线程数量很多，内存使用率很高，监控GC的日志发现full GC一直被调用，然后空间不能得到释放，主要是metaspace。然后这个版本和上个版本之间唯一的区别就是几个native sql。在

还是上一篇中提到过的API，通过调查我们发现这个API在需要返回的数据量比较大的有些单次调用中CPU可能达到90%到100%。所以即便是调用量不大的情况下，这个API一样是造成整个系统性能低下的最大贡献者。其中有一次调用返回时间更是长达10s。其实CPU的使用率高的话，响应时间自然就长，需要很长时间的计算才可以返回。优化的思路还是把单个查询分成多次，降低每次返回的数据集的大小。数据量比较大的表