January 19, 2017
聚簇索引(clustered index )和非聚簇索引(secondary index)的区别
"这两个名字虽然都叫做索引,但这并不是一种单独的索引类型,而是一种数据存储方式。对于聚簇索引存储来说,行数据和主键B+树存储在一起,辅助键B+树只存储辅助键和主键,主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来说,主键B+树在叶子节点存储指向真正数据行的指针,而非主键。\nInnoDB使用的是聚簇索引,将主键组织到一棵B+树中,而行数据就储存在叶子节点上,若使用”where id = 14″这样的条件查找主键,则按照B+树的检索算法即可查找到对应的叶节点,之后获得行数据。若对Name列进行条件搜索,则需要两个步骤:第一步在辅助索引B+树中检索Name,到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作,最终到达叶子节点即可获取整行数据。\nMyISM使用的是非聚簇索引,非聚簇索引的两棵B+树看上去没什么不同,节点的结构完全一致只是存储的内容不同而已,主键索引B+树的节点存储了主键,辅助键索引B+树存储了辅助键。表数据存储在独立的地方,这两颗B+树的叶子节点都使用一个地址指向真正的表数据,对于表数据来说,这两个键没有任何差别。由于索引树是独立的,通 …"
January 12, 2017
如何查询mysql事务未提交
"注意这篇文章并非死锁的,而是锁等待\n到information_schema库下面,查看下面这个表:\ninnodb_trx ## 当前运行的所有事务\ninnodb_locks ## 当前出现的锁\ninnodb_lock_waits ## 锁等待的对应关系\n如果遇到死锁了,怎么解决呢?找到原始的锁ID,然后KILL掉一直持有的那个线程就可以了, 但是众多线程,可怎么找到引起死锁的线程ID呢? MySQL 发展到现在,已经非常强大了,这个问题很好解决。 直接从数据字典连查找。\n我们来演示下。\n线程A,我们用来锁定某些记录,假设这个线程一直没提交,或者忘掉提交了。 那么就一直存在,但是数据里面显示的只是SLEEP状态。\nmysql\u0026gt; set @@autocommit=0;\nQuery OK, 0 rows affected (0.00 sec)\nmysql\u0026gt; use test;\nReading table information for completion oftableandcolumn names\nYou can turn off this feature to get a …"
January 9, 2017
mysql中的handler_read_%
"mysql\u0026gt; show status like ‘handler_read_%’;\n+———————–+——-+\n| Variable_name | Value |\n+———————–+——-+\n| Handler_read_first | 1 |\n| Handler_read_key | 1 |\n| Handler_read_last | 0 |\n| Handler_read_next | 0 |\n| Handler_read_prev | 0 |\n| Handler_read_rnd | 0 |\n| Handler_read_rnd_next | 21 |\n+———————–+——-+\n7 rows in set (0.01 sec)\n如上所示,mysql中关于read的计数器,有7个。他们的数值对于系统的状况的了解,对于系统的调优都十分重要。我们应该理解他们的含义。本文是自己的一些理解。 首先7个计数器,我们应该分为两部分: 1)对索引读的计数器:前面的5个都是对索引读情况的计数器, Handler_read_first:是指读索引的第一项(的次数); …"
December 20, 2016
gitlab修改时区
"刚装的系统,默认时间是UTC,比北京时间少了8个小时.\n修改 /var/opt/gitlab/gitlab-rails/etc/gitlab.yml 配置文件中的 time_zone : ‘Beijing’\n重启gitlab 即可\n#gitlab-ctl restart "
December 15, 2016
Linux系统排查
"常见工作中,计算机系统的资源主要包括CPU,内存,硬盘以及网络,过度使用这些资源将使系统陷入困境。本系列一共四篇博文,结合我在实习期间的学习,介绍一些常见的Linux系统排障工具及方法。\n第1篇—— 内存篇\n第2篇—— CPU篇\n第3篇—— 磁盘I/O篇\n第4篇—— 网络篇\n事实上,当上述服务器系统资源中的任何一个遭遇瓶颈,都会带来服务器性能的下降,典型的症状就是系统运行迟缓。\n本文从以下几个角度介绍Linux系统内存相关的排查。\n内存的使用率如何查看,使用率真的很高吗\n内存用在哪里了\n内存优化可以有哪些手段"
December 12, 2016
使用Gitlab一键安装包后的日常备份恢复与迁移
"Gitlab 创建备份 使用Gitlab一键安装包安装Gitlab非常简单, 同样的备份恢复与迁移也非常简单. 使用一条命令即可创建完整的Gitlab备份:\ngitlab-rake gitlab:backup:create 使用以上命令会在/var/opt/gitlab/backups目录下创建一个名称类似为1393513186_gitlab_backup.tar的压缩包, 这个压缩包就是Gitlab整个的完整部分, 其中开头的1393513186是备份创建的日期.\nGitlab 修改备份文件默认目录 你也可以通过修改/etc/gitlab/gitlab.rb来修改默认存放备份文件的目录:\ngitlab_rails[\u0026#39;backup_path\u0026#39;] = \u0026#39;/mnt/backups\u0026#39; /mnt/backups修改为你想存放备份的目录即可, 修改完成之后使用gitlab-ctl reconfigure命令重载配置文件即可.\nGitlab 自动备份 也可以通过crontab使用备份命令实现自动备份:\nsudo su - crontab -e 加入以下, 实现每天凌 …"
December 6, 2016
[Err] 1055 – Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column ‘information_schema.PROFILING.SEQ’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by的解决办法
"线上用的MySQL版本为5.7.11,线下用的5.6版本,发现将程序上线后,有些地方报这个错误\n[Err] 1055 – Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column ‘information_schema.PROFILING.SEQ’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by\nONLY_FULL_GROUP_BY: 对于GROUP BY聚合操作,若select中的列没有在group by中出现,那么这句SQL是不合法的。\n解决办法下my.cnf中添加以下几行\n[mysqld] …"