lidan3959的专栏

索引的建立，直接会影响到查询性能。看下面的查询：select * from ddd where id>1 order by score;我们查询学号大于1的学生的各科成绩得分。那么按照一般的思路，是这样建立索引的(id,score)。explain一下：[sql] view plaincopymysql> ex

今天早上到公司看到邮件告警，一个备库延迟巨大，奇怪为啥没告警，后来发现脚本告警被人注释，先不管这么多，查看主备相关信息show variables like '%commit%' 发现 主库设置为1，备库设置为2，这就奇怪了，主库业务不是特别大没道理延迟NN秒，然后有查看 show variables like '%sync%' 发现主备库都设置为1,然后默默尝试将备库设置为0，没多久

大家都知道varchar(N)当N大于255的时候mysql内部会转成text类型进行存储，所有很多人只要存储的字符串大于255都不加思考的就随便使用，其实这里还有一个区别就是查询当中是否使用临时表的问题，请看如下测试：字段说明：ref   varchar(1000) , org_id int ,id int 测试语句：show status like '%tmp%';sele

获得字符串列索引前缀长度大家都知道索引可以极大的加快查询的速度，但是索引也是有代价的，它需要消耗额外的存储空间，对数据的更新操作也涉及到对应索引的一致性更新。而对某些特殊的字符串索引来说，我们并不一定要整个字段长度都索引起来，只需要索引一定的前缀大小就可以达到快速查找指定数据的目的。比如name字段记录的是人的名字，定义为：name varchar(128) NOT

Summary of Online Status for DDL OperationsOperationIn-Place?Copies Table?Allows Concurrent DML?Allows Concurrent Query?NotesCREATE INDEX,ADD INDEX

今天本来想在开发测试机上做测试，测试过程中需要flush table ，不过让人想不到的是执行后居然卡住不动了。于是赶紧开启另一个会话查看情况如下：原来数据库里还有一个慢查询（已经执行了2w多秒），然后继续执行show processlist 观察，更多惊喜还在后面：所有的查询都在“waiting for table flush” ，够恐怖的吧（这让人想起了

今天看官方文档 发现一个关于多列索引的一个问题见链接：http://dev.mysql.com/doc/refman/5.5/en/multiple-column-indexes.html里面有这么一段话：Suppose that a table has the following specification:CREATE TABLE test ( id

废话先不多说，直接上实验情况。测试表结构如下：CREATE TABLE `test` (  `id` bigint(20) NOT NULL DEFAULT '0',  `stat_date` varchar(10) COLLATE utf8_bin DEFAULT NULL,  `earner_id` varchar(20) COLLATE utf8_bin DEFAULT NU

接着上一篇 MySQL 数据库性能优化之索引优化，这是 MySQL数据库性能优化专题 系列的第四篇文章：MySQL 数据库性能优化之SQL优化有人反馈之前几篇文章过于理论缺少实际操作细节，这篇文章就多一些可操作性的内容吧。注：这篇文章是以 MySQL 为背景，很多内容同时适用于其他关系型数据库，需要有一些索引知识为基础优化目标减少 IO 次数IO永远是数

相信有不少同仁已经做过过SSD作为存储对IO瓶颈的数据库性能测试，在得到可喜的成绩之余，在用于生产环境之前需要解决一些问题。InnoDB共享表空间包含：Data dictonaryDouble write bufferInsert bufferRollback segmentsUNDO space其中为了实现在脏数据异步回写到磁盘的过程中不造成页面（page）完

今天帮开发改写一个复杂的sql，具体sql就不列出剥离出核心sql类似如：select sum(xx) from a group by n1,n2,n3并且n1字段定义为varchar(255) 实际存储的数据长度一般都是不超过10左右个字符长度的数字字符串 如01500060，另外有一个主键id为自增字段当时 想建一个复合索引来测试一下看看索引如：  create index ind

背景         MySQL中在对某个字段做包含匹配时可以用like。先看这个结构和结果 CREATE TABLE `tb` (   `id` int(11) NOT NULL AUTO_INCREMENT,  `user_id` bigint(20) DEFAULT NULL,  `title` varchar(128)

EXISTS是一个非常强大的谓词，它允许数据库高效地检查指定查询是否产生某些行。通常EXISTS的输入是一个子查询，并关联到外部查询，但这并不一定是必须的。根据子查询是否返回行，该谓词返回TRUE或FALSE。例如下面的SQL语句：SELECT customerid,companynameFROM customers AS AWHERE country = 'Spain'     AND EX

MySQL5.0.37版本以上支持了Profiling – 官方手册。此工具可用来查询SQL 会执行多少时间，System lock和Table lock 花多少时间等等，对定位一条语句的I/O消耗和CPU消耗 非常重要。从启动profile之后的所有查询包括错误的语句都会记录。关闭会话或者set profiling=0 就关闭了。# 开启profilingmysql> se

说个案例：一台Apache服务器，由于其MaxClients参数设置过大，并且恰好又碰到访问量激增，结果内存被耗光，从而引发SWAP，进而负载攀升，最终导致宕机。正所谓：SWAP，性能之大事，死生之地，存亡之道，不可不察也。哪些工具可以监测SWAP最容易想到的就是free命令了，它指明了当前SWAP的使用情况：shell> free -m

前天线上出了个502错误，经排查是某开发人员写了条性感的程序吃掉了大部分内存，触发OOM-killer杀死Nginx查看日志/var/log/messages发现类似"Out of Memory: Kill process..."错误以前不了解OOM-killer{out of memory killer }，今天碰巧放假一天，借此学习下，涨涨姿势！ OOM_kil

原文作者： Alexander Rubin，Percona 工程师原文连接：Linux performance tuning tips for MySQL为了方面阅读，我没依照原文按行逐句的进行翻译。另外，我自己的扩充了一下基础知识点，很多知识点也是我第一次去学习，翻阅了一些资料。原文中对Linux系统参数的优化主要分为文件系统、内存与swap、CPU三方面。文

MySQL分库分表环境下全局ID生成方案 在大型互联网应用中，随着用户数的增加，为了提高应用的性能，我们经常需要对数据库进行分库分表操作。在单表时代，我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象。但是当我们对数据库进行了分库分表后，就不能依赖于每个表的自增ID来全局唯一标识这些数据了。因此，我们需要提供一个全局唯一的ID号生成策略来支持分库分表的环境。下面来介绍两

在Oracle 中我们知道有一个 Hierarchical Queries 通过CONNECT BY 我们可以方便的查了所有当前节点下的所有子节点。但很遗憾，在MySQL的目前版本中还没有对应的功能。 在MySQL中如果是有限的层次，比如我们事先如果可以确定这个树的最大深度是4, 那么所有节点为根的树的深度均不会超过4，则我们可以直接通过left join 来实现。