2013-06-01 31 views
8

CẬP NHẬT: vấn đề hiện tại là fixed.Làm cách nào để thực thi các truy vấn SQL mất nhiều thời gian hơn 99,999 giây trên MySQL Workbench?


Tôi muốn thực hiện truy vấn mất hơn 99,999 giây để thực thi (ví dụ: SELECT SLEEP(150000);). Để thay đổi thời gian chờ trong MySQL Workbench, chúng tôi phải chuyển đến Chỉnh sửa → Tùy chọn → Trình chỉnh sửa SQL → Thời gian đọc kết nối DBMS (tính bằng giây). Tuy nhiên, trường DBMS connection read time out chỉ chấp nhận tối đa 5 số và đặt trường thành 0 tương đương với tham số mặc định (600 giây). Nếu truy vấn mất nhiều thời gian hơn thời gian chờ, tôi nhận được thông báo lỗi: Error Code: 2013. Lost connection to MySQL server during query

Do đó câu hỏi của tôi: có thể tăng giới hạn này lên hơn 99,999 giây không? Tôi sử dụng Windows 7 64-bit Ultimate với MySQL Workbench 5.2.47 CE.

Các DBMS connection read time out lĩnh vực: enter image description here

Timeout vấn đề (0 tương đương với các thông số mặc định (600 giây)): enter image description here

+0

Không. Và nghiêm túc? Bạn cần phải tự chạy một truy vấn mất hơn 27 giờ? Có lẽ bạn nên đánh giá lại tình hình ... – GreyBeardedGeek

+0

Bạn thực sự không nên chạy truy vấn trong quá trình sản xuất mất hơn một vài phút. Nếu có nhiều dữ liệu, hãy chạy dữ liệu theo từng lô nhỏ. – Aaronaught

+1

Xin cảm ơn! Tôi cần trích xuất một số thông tin từ một bảng 50 GB và đặt chúng vào một bảng mới. Trong quá trình trích xuất này, tôi thực hiện một số tham gia trong bộ nhớ để thay thế một số thuộc tính văn bản bằng ID tương ứng (khóa ngoài). Tôi không hiểu tại sao truy vấn này mất hơn 99,999 giây, nhưng trong khi tôi điều tra nó chạy một số 'GIẢI THÍCH', tôi đã tò mò muốn biết nếu có bất kỳ cách nào để vượt qua giới hạn 99.999 giây này trong MySQL Workbench. Thông thường thiết lập tham số 0 có nghĩa là vô hạn: có bất kỳ vấn đề kỹ thuật nào giải thích tại sao MySQL Workbench không cho phép điều đó? –

Trả lời

4

Có lẽ không ai nghĩ rằng bạn sẽ cần một thời gian chờ cao như vậy, vì vậy bạn được giới hạn cho những gì là settable hiện tại. Nhưng mở yêu cầu tính năng trên http://bugs.mysql.com để đề xuất có 0 tắt toàn bộ thời gian chờ hoặc cho phép các giá trị lớn hơn không.

+0

Cảm ơn, đã thực hiện: http://bugs.mysql.com/bug.php?id=69395 –

+0

Lỗi này hiện đã được sửa. –

1

Vâng, ở châu Âu, chúng tôi xem xét các dấu phẩy một số thập phân-tách. Bạn đã thực sự có nghĩa là 100k giây? Tôi thấy trong ý kiến ​​của bạn rằng bạn đang xử lý 50 GB. Mặc dù vậy, nếu bạn cần nhiều hơn một giờ, bạn đã bỏ lỡ các Indeces. Bạn phải biết rằng họ sẽ không xây dựng lại đúng cách trong một truy vấn đơn lẻ, vì vậy nếu bạn tham gia vào quá trình chèn lớn, bạn sẽ nhận được sản phẩm Descartes của các hàng được quét - nói cách khác, truy vấn của bạn có thể xảy ra trong nhiều tuần hoặc thậm chí hàng tháng.

Giải pháp:

1) Điền dữ liệu cơ bản, không sử dụng kết nối tại đây. 2) Thay đổi bảng để đặt chỉ mục. 3) Chạy "ANALYZE" 4) Thực hiện mọi thứ khác.

Nếu yo cảm thấy bạn gặp khó khăn sau thủ tục đó, hãy thêm truy vấn của bạn bằng từ khóa EXPLAIN và đăng kết quả.

(Tôi có một cronjob nhập khẩu khoảng 80GB mỗi 30 phút tại chỗ - MySQL chắc chắn có thể xử lý này.)

+0

Cảm ơn lời khuyên, vâng tôi có nghĩa là 100k giây. Sử dụng chỉ số thực sự cho phép giảm thời gian chạy xuống 1 giờ chỉ cho truy vấn cụ thể bắt đầu câu hỏi này, nhưng tôi vẫn tò mò muốn biết trong MySQL Workbench cách tôi có thể thực hiện truy vấn mất hơn 99,999 giây :) Tôi không thấy điểm trong việc đưa ra một giới hạn như vậy. –

1

Sự cố này hiện được giải quyết trong MySQL Workbench 6.0.3 (2013-07-09): Xem bug reportchange log.

Các vấn đề liên quan