MySQL INSERT INTO bảng GIÁ TRỊ .. so với INSERT INTO bảng SET


252

Sự khác biệt chính giữa INSERT INTO table VALUES ..và là INSERT INTO table SETgì?

Thí dụ:

INSERT INTO table (a, b, c) VALUES (1,2,3)

INSERT INTO table SET a=1, b=2, c=3

Và những gì về hiệu suất của hai?


12
Sau khi đọc Code Complete và sự nhấn mạnh liên tục của McConnell về khả năng đọc, có vẻ đáng tiếc đó INSERT INTO table SETkhông phải là tiêu chuẩn. Có vẻ rõ ràng hơn nhiều. Tôi đoán INSERT INTO table ([column name, column name b]) VALUES (['value a', 'value b'])dù sao tôi cũng sẽ phải sử dụng cú pháp để tự cứu mình khỏi rắc rối nếu tôi chuyển sang Postgres.
clulesscoder

Câu trả lời:


195

Theo như tôi có thể nói, cả hai cú pháp đều tương đương nhau. Đầu tiên là tiêu chuẩn SQL, thứ hai là phần mở rộng của MySQL.

Vì vậy, họ nên được chính xác hiệu suất tương đương khôn ngoan.

http://dev.mysql.com/doc/refman/5.6/en/insert.html nói:

INSERT chèn các hàng mới vào một bảng hiện có. Các dạng INSERT ... VALUES và INSERT ... SET của câu lệnh chèn các hàng dựa trên các giá trị được chỉ định rõ ràng. Biểu mẫu CHỌN ... CHỌN chèn các hàng được chọn từ một bảng hoặc bảng khác.


4
Làm thế nào để bạn CHỌN nhiều giá trị bằng cách sử dụng INSERT INTO table SET? Điều này thậm chí có thể?
pixelfreak

2
Ý anh là gì? Ví dụ mà OP đã nói SET a = 1, b = 2, c = 3 là nhiều giá trị theo cách hiểu của tôi.
Vinko Vrsalovic

9
Ý tôi là, CHỌN nhiều hàng. Giống như: bảng INSERT INTO (a, b, c) GIÁ TRỊ (1,2,3), (4,5,6), (7,8,9);
pixelfreak

5
Chỉ các câu lệnh INSERT sử dụng cú pháp VALUES mới có thể chèn nhiều hàng.
Vinko Vrsalovic

8
@VinkoVrsalovic, không đúng, chèn chọn cũng có thể chèn nhiều hàng khi nhiều hàng được chọn
Pacerier

15

Tôi nghĩ rằng tiện ích mở rộng nhằm mục đích cho phép một cú pháp tương tự để chèn và cập nhật. Trong Oracle, một thủ thuật cú pháp tương tự là:

UPDATE table SET (col1, col2) = (SELECT val1, val2 FROM dual)

5
@Pacerier Chẳng hạn như? Vấn đề duy nhất tôi thấy là vấn đề về tính di động (trong nhiều bối cảnh không thực sự quan trọng); tui bỏ lỡ điều gì vậy?
Đánh dấu Amery

1
@MarkAmery, vâng khi bạn nhìn vào nó, không có lợi ích thực sự. Nhược điểm là lãng phí thời gian không cần thiết , toàn bộ sự tồn tại của chủ đề này chứng minh quan điểm của tôi.
Pacerier

8
@Pacerier Tôi không chắc là tôi thấy quan điểm của bạn? Lãng phí thời gian nào? Có một lợi ích, đã được chỉ ra: bạn chỉ cần lặp qua một mảng các cặp khóa / giá trị một lần để tạo câu lệnh INSERT của bạn, thay vì hai lần như bạn cần sử dụng cú pháp VALUES, dẫn đến ngắn hơn, rõ ràng hơn và mã nhanh hơn để viết.
Đánh dấu Amery

@MarkAmery nhưng thủ thuật tiên tri này không lợi ích đó. Bạn đặt tên cho tất cả các cột trước, sau đó là tất cả các giá trị.
hobbs 2/213

12
@Pacerier Đó là một điểm công bằng, và có một sự đánh đổi để được cân nhắc. Chống lại tính năng bạn có vấn đề về tính di động và lãng phí thời gian nghiên cứu sự khác biệt giữa INSERT ... SET ...INSERT ... VALUES .... Đối với tính năng bạn có mã ngắn hơn, viết nhanh hơn, tăng khả năng đọc và loại bỏ lỗi chính tả gây ra bằng cách trộn thứ tự cột khi viết VALUESmệnh đề của bạn . Ruột của tôi nói với tôi rằng trên mạng cái tốt hơn cái xấu, nhưng phán đoán của bạn có thể khác.
Đánh dấu Amery

4

Vì các cú pháp là tương đương (dù sao trong MySQL), tôi thích INSERT INTO table SET x=1, y=2cú pháp hơn, vì nó dễ sửa đổi hơn và dễ bắt lỗi hơn trong câu lệnh, đặc biệt là khi chèn nhiều cột. Nếu bạn phải chèn 10 hoặc 15 cột trở lên, theo tôi, thật dễ dàng để trộn một cái gì đó bằng cách sử dụng (x, y) VALUES (1,2)cú pháp.

Nếu tính di động giữa các tiêu chuẩn SQL khác nhau là một vấn đề, thì có lẽ INSERT INTO table (x, y) VALUES (1,2)sẽ được ưu tiên.

Và nếu bạn muốn chèn nhiều bản ghi vào một truy vấn, có vẻ như INSERT INTO ... SETcú pháp sẽ không hoạt động, trong khi đó một cú pháp khác sẽ làm. Nhưng trong hầu hết các trường hợp thực tế, bạn đang lặp qua một tập hợp các bản ghi để thực hiện chèn bất kỳ cách nào, mặc dù có thể có một số trường hợp có thể xây dựng một truy vấn lớn để chèn một loạt các hàng vào một bảng trong một truy vấn, so với truy vấn cho mỗi hàng, có thể có một cải tiến hiệu suất. Thực sự không biết.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.