从开始使用mysql起, 就觉得:
1. 索引的使用对innodb的性能的影响是很大的, 在做explain的时候, 当extra中出现了filesort的时候一般就意味者低效率和应当优化sql语句
2. 在select语句中, where中用到的条件字段order by中的字段最好是同一个(些)字段(假定只有都只有一个(些)字段), 且这个字段最好是有索引的, 这样在explain的时候, type就会是index, 且extra中不会有filesort; 如果where中的字段和order by的字段不一样的话, 则可能出现filesort, 从而会导致低效
在实际中遇到了一个例子, 发现上面的理解其实是比较片面的, 这个例子的大体情况是:
表t_mytable中有字段F_time_1和F_time_2,分别是datatime, 且分别都有索引;字段F_pid是主键
1. 运行sql语句 SELECT … FROM t_mytable WHERE F_pid=’val’ AND F_time_1>= ‘time1′ AND F_TIME_1 <= ‘time2′ ORDER BY F_time_1, 记录条目是12条, 但发现效率很低;觉得很奇怪:这个语句的效率应该高才对的
2. 尝试着改了一下sql语句为SELECT … FROM t_mytable WHERE F_pid=’val’ AND F_time_2>= ‘time1′ AND F_TIME_2 <= ‘time2′ ORDER BY F_time_1,记录条目是8条,效率很高;
阅读全文…
相关日志
第一部分, innodb的线程模型:
innodb内部大体上有三类线程, 主线程(只有一个); 用户线程 , 用户线程根据不同的职责也可以分成两类; 辅助线程
整个innodb由一个主线程控制, 这个线程是innodb一起来的时候就开始运行(入口函数是srv_master_thread), 它的优先级相对于其他innodb内部的线程来说优先级较高, 大部分时间下, 这个线程处于sleep状态, 每隔一定间隔这个线程起来看看是否有什么任务需要处理,这些任务包括:
1. drop延迟删除的表(如果有的话)
阅读全文…
相关日志
innodb的同步管理
数据库是支持多客户端同时连接和处理的, 因此多线程是必然的,多线程编码很重要的一个方面是处理同步和互斥,innodb的互斥机制有两个:mutex和rw-lock; 当某个线程需要获取一个mutex或rw-lock时,有两种结果可能发生, 一是直接获得了mutex从而继续处理;一个是无法获得mutex只得等待拥有线程释放mutex. 多线程编码技术中, 是通过信号量来通知等待线程mutex的可用性的, mysql在处理时并没有直接使用操作系统提供的信号量机制, 而是实现了自己的信号量机制,之所以不用操作系统的信号量机制而自己实现的主要原因是操作系统的信号量机制比较慢,其次一个原因是(某些)操作系统的信号量处理往往导致线程切换,而在很多时候, 有比不做线程切换更高效的事情:在多处理器系统上,通过循环等待旋转锁(spin lock), 当然, 在只有单处理器的系统上,循环等待明显是低效的事情。再一个原因是, 便于分析同步情况, 从而避免死锁, 因为当所有的同步信息交给操作系统处理时, 就难以分析死锁情况了,如果有自己的数据结构来管理这些信息, 死锁情况就容易分析。
阅读全文…
相关日志