Truy vấn MySQL Khởi động lại sau mỗi 60 giây?

Question

Tôi gặp vấn đề lạ. Tôi đang chạy một truy vấn MySQL đối với một bảng rất lớn từ PHP. Thời gian truy vấn là hơn một phút, nhưng đó không phải là vấn đề của tôi. Có vẻ như PHP đang gửi lại truy vấn sau mỗi 66 giây.

show processlist; 
+--------+---------+-------------------+----------+---------+------+---------------+-------------------------------------------------------- 
| Id  | User | Host    | db  | Command | Time | State   | Info             
+--------+---------+-------------------+----------+---------+------+---------------+-------------------------------------------------------- 
| 150018 | root | localhost   | amrs  | Query | 32 | Sending data | /*DEREK*/select ctlno, count(*) AS count from (omitted) 

Một vài phút sau, tôi đã kiểm tra một lần nữa:

+--------+---------+-------------------+----------+---------+------+---------------+-------------------------------------------------------- 
| Id  | User | Host    | db  | Command | Time | State   | Info             
+--------+---------+-------------------+----------+---------+------+---------------+-------------------------------------------------------- 
| 150018 | root | localhost   | amrs  | Query | 188 | Sending data | /*DEREK*/select ctlno, count(*) AS count from (omitted) 
| 150021 | root | localhost   | amrs  | Query | 122 | Sending data | /*DEREK*/select ctlno, count(*) AS count from (omitted) 
| 150023 | root | localhost   | amrs  | Query | 56 | Sending data | /*DEREK*/select ctlno, count(*) AS count from (omitted) 

Tôi đã không được nạp lại trang hoặc bất cứ điều gì. set_time_limit (0) được gọi gần đầu của tập lệnh. Phần gây phiền nhiễu là, trang dường như được liên kết với trang chạy gần đây nhất. Vì vậy, nếu tôi giết 150018, không có gì xấu xảy ra, nhưng nếu tôi giết 150023 trước khi một cái khác được sinh ra, trang sẽ xuất hiện với một lỗi "Thực hiện truy vấn bị gián đoạn". 150018 cuối cùng sẽ tự kết thúc chạy nhưng nó không thực hiện tốt bởi vì tập lệnh/trang sẽ không nhận được.

Bất kỳ ai có ý tưởng nào?

EDIT: hiển thị đầy đủ processlist đưa ra sau (với một số dòng loại bỏ cho ngắn gọn và bảo mật):

+--------+---------+-------------------+----------+---------+-------+--------------+----------------------------------------------------- 
| Id  | User | Host    | db  | Command | Time | State  | Info 
+--------+---------+-------------------+----------+---------+-------+--------------+----------------------------------------------------- 
| 147385 | root | localhost:44560 | amrs  | Sleep | 14021 |    | NULL 
| 150248 | root | localhost   | NULL  | Query |  0 | NULL   | show full processlist 
| 150251 | root | localhost   | amrs  | Query |  1 | statistics | /*DEREK*/select ctlno, count(*) AS count from (snip) 
+--------+---------+-------------------+----------+---------+-------+--------------+----------------------------------------------------- 

Answer 1

Tôi đã thấy một vấn đề tương tự một vài lần trước đây, và các vấn đề của bạn âm thanh rất giống với những gì tôi đã trải qua làm việc với một trang web trước đó.

Bạn có đang truy cập máy chủ proxy khi truy cập trang web không?

Điều gì đã xảy ra với trang web của tôi, là các truy vấn từ một nhóm người dùng cụ thể trong cùng một công ty đang được chuyển hướng qua máy chủ proxy của họ. sẽ chỉ phát lại yêu cầu web mà không thông báo cho trình duyệt của khách hàng rằng điều này đã xảy ra! Vì vậy, với các truy vấn chạy dài nhất định mất hơn một phút để thực thi, tôi sẽ thấy các truy vấn bắt đầu kết hợp với nhau và tôi sẽ xem xét danh sách quy trình với các truy vấn giống hệt nhau đang chạy, mỗi cách nhau gần đúng 60 giây!

Độ phân giải cho điều này là giúp khách hàng bằng cách chuyển máy chủ proxy của họ cho trang web của chúng tôi.

Trường hợp thứ hai của cùng một vấn đề chính xác này đã được giải quyết khi khách hàng nâng cấp máy chủ proxy của họ lên phiên bản mới nhất.

Tôi rất tiếc, nhưng tôi không thể nhớ máy chủ proxy nào được sử dụng trong cả hai trường hợp, vì đã khá vài tháng trước và tôi đã ngủ kể từ đó: -/