标签MySQL下的文章

Jerry Bendy 发布于 11月28, 2015

mysqli使用localhost问题 Warning: mysqli::mysqli(): (HY000/2002): No such file or directory

今天在使用PHP的CLI方式访问mysql数据库时出现了一个 No such file or directory的错误,查找资料并在最终解决后记录一下。

这个问题应该也会存在于非CLI方式访问,简单的代码是这样的:

<?php
$mysqli = new mysqli('localhost', 'root', 'root', 'test');

如果上面的连接地址是 localhost 就会报此错误,改成 127.0.0.1 后正常。

当主机填写为localhost时MySQL会采用 unix domain socket连接,当主机填写为127.0.0.1时MySQL会采用TCP/IP的方式连接。使用Unix socket的连接比TCP/IP的连接更加快速与安全。这是MySQL连接的特性,可以参考官方文档的说明4.2.2. Connecting to the MySQL Server

这个问题有以下几种解决方法:

使用TCP/IP代替Unix socket。即在连接的时候将localhost换成127.0.0.1。 修改MySQL的配置文件my.cnf,指定mysql.socket的位置:

/var/lib/mysql/mysql.sock (你的mysql.socket路径)。

直接在php建立连接的时候指定my.socket的位置(官方文档:mysqli_connect)。比如:

$db = new MySQLi('localhost', 'root', 'root', 'my_db', '3306', '/var/run/mysqld/mysqld.sock')

通常意义上localhost和127.0.0.1是等价的,只是mysql在处理这个名词的问题上有一些不同,是根据不同的地址来采取的不同的通信手段。

问题的最终解决方案是在连接的时候手动指定了 sock 文件的路径

原因呢,我猜大概是为了本地应用能获得更好的性能。而且localhost这个地址在mysql中也不会做匹配。即user@'%'不能匹配到user@'localhost'

阅读全文 »

Jerry Bendy 发布于 09月02, 2015

断网时本地连接MySQL速度慢-MySQL的DNS反向解析

今天由于意外情况公司断网,测试程序时跑在另一台虚拟机里面的mysql服务发现连接特别慢(在10秒左右),多方查找资料最终定位问题在MySQL的DNS反向解析上面。

MySQL数据库收到一个网络连接后,首先拿到对方的IP地址,然后对这个IP地址进行反向DNS解析从而得到这个IP地址对应的主机名。用主机名在权限系统里面进行权限判断。反向DNS解析是耗费时间的,有可能让用户感觉起来很慢。甚至有的时候,反向解析出来的主机名并没有指向这个IP地址,这时候就无法连接成功了。

想要临时关闭DNS反向解析也比较简单,可以有下面两种方法:

一、命令行方式执行

/usr/local/mysql/bin/mysqld_safe --skip-name-resolve --user=mysql &amp;

二、修改mysql配置文件,打开my.cnf,找到[mysqld]段,在下面追加(Windows和Linux通用)

skip-name-resolve

退出并重启MySQL服务即可

阅读全文 »

Jerry Bendy 发布于 11月09, 2013

高效MySQL分页方法

PERCONA PERFORMANCE CONFERENCE 2009上,来自雅虎的几位工程师带来了一篇”Efficient Pagination Using MySQL“的报告,有很多亮点,本文是在原文基础上的进一步延伸。

首先看一下分页的基本原理:

mysql> explain SELECT * FROM message ORDER BY id DESC LIMIT 10000, 20G
***************** 1\. row **************
id: 1
select_type: SIMPLE
table: message
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 10020
Extra:
1 row in set (0.00 sec)

limit 10000,20的意思扫描满足条件的10020行,扔掉前面的10000行,返回最后的20行,问题就在这里,如果是limit 100000,100,需要扫描100100行,在一个高并发的应用里,每次查询需要扫描超过10W行,性能肯定大打折扣。文中还提到limit n性能是没问题的,因为只扫描n行。

文中提到一种”clue”的做法,给翻页提供一些”线索”,比如还是SELECT * FROM message ORDER BY id DESC,按id降序分页,每页20条,当前是第10页,当前页条目id最大的是9527,最小的是9500,如果我们只提供”上一页”、”下一页”这样的跳转(不提供到第N页的跳转),那么在处理”上一页”的时候SQL语句可以是:

SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20;

处理”下一页”的时候SQL语句可以是:

SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 20;

不管翻多少页,每次查询只扫描20行。

缺点是只能提供”上一页”、”下一页”的链接形式,但是我们的产品经理非常喜欢”<上一页 1 2 3 4 5 6 7 8 9 下一页>”这样的链接方式,怎么办呢?

如果LIMIT m,n不可避免的话,要优化效率,只有尽可能的让m小一下,我们扩展前面的”clue”做法,还是SELECT * FROM message ORDER BY id DESC,按id降序分页,每页20条,当前是第10页,当前页条目id最大的是9527,最小的是9500,比如要跳到第8页,我看的SQL语句可以这样写:

SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;

跳转到第13页:

SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 40,20;

原理还是一样,记录住当前页id的最大值和最小值,计算跳转页面和当前页相对偏移,由于页面相近,这个偏移量不会很大,这样的话m值相对较小,大大减少扫描的行数。其实传统的limit m,n,相对的偏移一直是第一页,这样的话越翻到后面,效率越差,而上面给出的方法就没有这样的问题。

注意SQL语句里面的ASC和DESC,如果是ASC取出来的结果,显示的时候记得倒置一下。

已在60W数据总量的表中测试,效果非常明显。

转载自:http://www.fuchaoqun.com/2009/04/efficient-pagination-using-mysql/

阅读全文 »