Question

最近，我的网站一直在生成“无法连接到mysql数据库”的错误。不是所有的时间，偶尔（在高流量时间）。

我向我的托管公司询问了这个问题，他们回复说我的查询速度很慢（> 1秒）。记录这些查询，我花了很多时间浏览日志文件，但没有出现任何模式。文件中有各种各样的查询：我写过的一些查询，还有一些来自第三方软件，如Mediawiki和Omeka。所有这些非常不同的查询都可能出现问题，这似乎很奇怪。

我尝试在某些查询中使用MySQL“解释”功能，这似乎没有显示任何问题（我认为我不是解释“解释”结果的专家）。'

我正在共享托管计划，允许15个MySQL同时连接。我在所有数据库上运行“修复”功能都没有效果。

所以，我的问题：除了查询本身的结构之外，我应该将其视为对缓慢的解释吗？

感谢您提供任何建议。

=============================================== ================

所要求的其他信息：

以下是两个查询及其“解释”结果。关于共享主机上的配置，它是带有mod_php的Apache。

好的，这里有一些例子。

这是一个查询工作人员信息的查询（电子邮件x-ed out）。 staff表有＆lt; 100行。

# Wed Oct  7 00:32:58 2015
# Thread_id: 500674  Schema: ithacali_live  Last_errno: 0  Killed: 0
# Query_time: 2.402803  Lock_time: 0.017267  Rows_sent: 1  Rows_examined: 59  Rows_affected: 0  Rows_read: 59
# Bytes_sent: 1450
use ithacali_live;
SET timestamp=1444199578;
SELECT s.staff_id, s.lname, s.fname, s.title, s.tel, s.email, d.name, bio, subject_id
FROM staff s
LEFT JOIN department d on s.department_id = d.department_id
LEFT JOIN staff_subject ss ON s.staff_id = ss.staff_id
WHERE s.email = 'xxxx@xxxxx.edu'
GROUP BY s.lname

+----+-------------+-------+--------+----------------------------+------------------+---------+-------------------------------+------+-------------+
| id | select_type | table | type   | possible_keys              | key              | key_len | ref                           | rows | Extra       |
+----+-------------+-------+--------+----------------------------+------------------+---------+-------------------------------+------+-------------+
|  1 | SIMPLE      | s     | index  | NULL                       | INDEXSEARCHstaff | 516     | NULL                          |    3 | Using where |
|  1 | SIMPLE      | d     | eq_ref | PRIMARY                    | PRIMARY          | 4       | ithacali_live.s.department_id |    1 |             |
|  1 | SIMPLE      | ss    | ref    | PRIMARY,fk_ss_staff_id_idx | PRIMARY          | 4       | ithacali_live.s.staff_id      |   25 | Using index |
+----+-------------+-------+--------+----------------------------+------------------+---------+-------------------------------+------+-------------+
3 rows in set (0.00 sec)

这是我们自己开发的CMS中的一个。 “pluslet”表包含~8,000行和“subject”约700个。

# Wed Oct  7 21:46:02 2015
# Thread_id: 756435  Schema: ithacali_live  Last_errno: 0  Killed: 0
# Query_time: 6.854625  Lock_time: 0.000179  Rows_sent: 10  Rows_examined: 30  Rows_affected: 0  Rows_read: 30
# Bytes_sent: 7956
use ithacali_live;
SET timestamp=1444275962;
SELECT p.pluslet_id, p.title, p.body, ps.pcolumn, p.type, p.extra
    FROM pluslet p, subject s, pluslet_subject ps
    WHERE p.pluslet_id = ps.pluslet_id
    AND s.subject_id = ps.subject_id
    AND s.subject_id = '246'
    ORDER BY prow ASC

+----+-------------+-------+--------+-------------------------------------------+----------------------+---------+-----------------------------+------+-----------------------------+
| id | select_type | table | type   | possible_keys                             | key                  | key_len | ref                         | rows | Extra                       |
+----+-------------+-------+--------+-------------------------------------------+----------------------+---------+-----------------------------+------+-----------------------------+
|  1 | SIMPLE      | s     | const  | PRIMARY                                   | PRIMARY              | 8       | const                       |    1 | Using index; Using filesort |
|  1 | SIMPLE      | ps    | ref    | fk_sp_pluslet_id_idx,fk_sp_subject_id_idx | fk_sp_subject_id_idx | 8       | const                       |   10 | Using where                 |
|  1 | SIMPLE      | p     | eq_ref | PRIMARY                                   | PRIMARY              | 4       | ithacali_live.ps.pluslet_id |    1 |                             |
+----+-------------+-------+--------+-------------------------------------------+----------------------+---------+-----------------------------+------+-----------------------------+
3 rows in set (0.00 sec)

Answer 1

您有导致问题的查询，而这正是解决问题所需的问题。我们处理这个的方式如下。我们首先解决在慢查询日志中花费最长时间的查询，然后我们解决经常出现的查询（例如，更新Joomla网站上的#__session表）。

现在解决查询可以是以下之一：

重写查询
删除重复的查询
限制查询。例如，如果您的主页有类似的内容：

SELECT * FROM table_name LIMIT 0,20

并且table_name有类似于100k的文章，主页只检索最后20篇，然后你可以做类似的事情

 SELECT * FROM `table_name` WHERE `id` > 99,000 LIMIT 0, 20

（当然，上面的查询假定了连续的ID，因此应该用适合您情况的东西替换99,000，并且必须每隔一段时间更新一次。）

索引一些应该已编入索引但不是
更改某些字段的类型（某些表使用文本字段，字段不超过64个字符，并且应为VARCHAR类型而不是TEXT）
修改数据库的配置以适应服务器上的负载

Answer 2

共享主机将成为一场噩梦，它们总是会过度使用计算资源并根据您的MySQL日志判断 - 您的查询不是那么重，它们检查的行数不到1000行，这是所有标准非常非常低的。 / p>

我问过PHP执行模型。原因是php-fpm非常资源友好，特别是在连接MySQL时，因为它能够打开一次连接并保持打开以便后续访问。通常，php-fpm的实例将打开与MySQL一样多的连接，因为有子进程（我没有超过8个）。使用mod_php时，这种情况不会发生，完全相反 - 它不是资源友好的。

可能正在发生什么，因为您在共享主机上 - 其他人正在使用硬盘资源（I / O，bandith）而你正在陷入有限的资源。这是将网站转移到专用主机的常见原因 - 所以其他人不会吃午餐。您可以尝试根据需要优化代码，但是您受到PHP执行模型以及共享资源的限制。

这篇文章的目的是告诉你，至少有一些事实，你的共享主持人在这个阶段根本不会为你削减它。没有多少编程可以解决资源不足的问题。

缓慢的MySQL查询的解释？

2 个答案: