Bạn sẽ không biết trạng thái thực của kết nối nếu không xem qua dây và SELECT 1 là một ứng cử viên đủ tốt (có thể cho rằng bạn có thể nghĩ ra một lệnh ngắn hơn, mất ít thời gian hơn để phân tích cú pháp, nhưng so với mạng hoặc thậm chí độ trễ lặp lại, những khoản tiết kiệm đó sẽ không đáng kể.)
Điều này đang được nói, tôi sẽ tranh luận rằng ping một kết nối trước đó kiểm tra nó từ hồ bơi không phải là cách tiếp cận tốt nhất .
Bạn có thể chỉ cần yêu cầu trình quản lý nhóm kết nối của mình thực thi chính sách duy trì hoạt động (thời gian chờ) của chính nó để tránh bị ngắt kết nối bởi máy chủ (ngắn gọn là sự cố kết nối can thiệp nghiêm trọng hơn, có thể ảnh hưởng đến bạn dù sao vẫn đang hoạt động bình thường - và dù sao thì trình quản lý nhóm kết nối của bạn cũng không thể trợ giúp), cũng như để không làm hỏng cơ sở dữ liệu (nghĩ rằng xử lý tệp và sử dụng bộ nhớ) không cần thiết.
Do đó, theo ý kiến của tôi, có vấn đề là kiểm tra giá trị nào cho điều kiện kết nối trước khi kiểm tra kết nối từ pool thực sự có. Có thể đáng để kiểm tra trạng thái kết nối trước khi kiểm tra lại kết nối vào nhóm , nhưng điều đó có thể được thực hiện ngầm bằng cách chỉ cần đánh dấu kết nối là bẩn khi phát sinh lỗi cứng SQL (hoặc ngoại lệ tương đương) (trừ khi API bạn đang sử dụng lộ ra is-bad -như cuộc gọi cho bạn.)
Do đó, tôi muốn giới thiệu:
- triển khai một chính sách tồn tại lâu dài ở phía khách hàng
- không thực hiện bất kỳ kiểm tra nào khi kiểm tra các kết nối từ nhóm
- thực hiện kiểm tra bẩn trước khi kết nối được đưa trở lại nhóm
- để mã ứng dụng giải quyết các điều kiện kết nối đặc biệt (không hết thời gian chờ) khác
CẬP NHẬT
Từ nhận xét của bạn có thể thấy rằng bạn thực sự thực sự muốn ping kết nối (tôi cho rằng đó là do bạn không có toàn quyền kiểm soát hoặc không có kiến thức về đặc điểm thời gian chờ trên máy chủ MySQL hoặc thiết bị mạng can thiệp như proxy, v.v.)
Trong trường hợp này, bạn có thể sử dụng DO 1
thay thế cho SELECT 1; nó là ngoài lề nhanh hơn - phân tích cú pháp ngắn hơn và nó không trả về dữ liệu thực tế (mặc dù bạn sẽ lấy TCP ack s, vì vậy bạn vẫn sẽ thực hiện xác thực khứ hồi rằng kết nối vẫn được thiết lập.)
CẬP NHẬT 2
Về bài đăng của Joshua , đây là dấu vết chụp gói cho các tình huống khác nhau:
SELECT 1;
13:51:01.463112 IP client.45893 > server.mysql: P 2270604498:2270604511(13) ack 2531191393 win 1460 <nop,nop,timestamp 2983462950 59680547>
13:51:01.463682 IP server.mysql > client.45893: P 1:57(56) ack 13 win 65306 <nop,nop,timestamp 59680938 2983462950>
13:51:01.463698 IP client.45893 > server.mysql: . ack 57 win 1460 <nop,nop,timestamp 2983462951 59680938>
DO 1;
13:51:27.415520 IP client.45893 > server.mysql: P 13:22(9) ack 57 win 1460 <nop,nop,timestamp 2983488906 59680938>
13:51:27.415931 IP server.mysql > client.45893: P 57:68(11) ack 22 win 65297 <nop,nop,timestamp 59681197 2983488906>
13:51:27.415948 IP client.45893 > server.mysql: . ack 68 win 1460 <nop,nop,timestamp 2983488907 59681197>
mysql_ping
14:54:05.545860 IP client.46156 > server.mysql: P 69:74(5) ack 78 win 1460 <nop,nop,timestamp 2987247459 59718745>
14:54:05.546076 IP server.mysql > client.46156: P 78:89(11) ack 74 win 65462 <nop,nop,timestamp 59718776 2987247459>
14:54:05.546092 IP client.46156 > server.mysql: . ack 89 win 1460 <nop,nop,timestamp 2987247459 59718776>
Như bạn có thể thấy, ngoại trừ thực tế là mysql_ping gói là 5 byte thay vì DO 1; 9 byte, số vòng quay (và do đó, độ trễ do mạng gây ra) hoàn toàn giống nhau. Chi phí bổ sung duy nhất bạn phải trả bằng DO 1 trái ngược với mysql_ping là phân tích cú pháp của DO 1 , điều này thật tầm thường.
