Lý do không sử dụng chọn * là gì?


136

Tôi đã thấy một số người tuyên bố rằng bạn nên đặt tên cụ thể cho từng cột bạn muốn trong truy vấn đã chọn.

Giả sử tôi sẽ sử dụng tất cả các cột, tại sao tôi không sử dụng SELECT *?

Ngay cả khi xem xét câu hỏi * Truy vấn SQL - Chọn * từ chế độ xem hoặc Chọn col1, col2, trục colN từ chế độ xem *, tôi không nghĩ đây là một bản sao chính xác khi tôi tiếp cận vấn đề từ góc độ hơi khác.

Một trong những nguyên tắc của chúng tôi là không tối ưu hóa trước thời gian. Với ý nghĩ đó, có vẻ như sử dụng SELECT *nên là phương pháp ưa thích cho đến khi nó được chứng minh là một vấn đề tài nguyên hoặc lược đồ được đặt khá nhiều. Điều mà, như chúng ta biết, sẽ không xảy ra cho đến khi hoàn thành phát triển.

Điều đó nói rằng, có một vấn đề quan trọng hơn để không sử dụng SELECT *?

Câu trả lời:


168

Bản chất của trích dẫn không tối ưu hóa sớm là sử dụng mã đơn giản và đơn giản và sau đó sử dụng sử dụng một trình lược tả để chỉ ra các điểm nóng, sau đó bạn có thể tối ưu hóa để có hiệu quả.

Khi bạn sử dụng select * bạn không thể lập hồ sơ, do đó bạn không viết mã rõ ràng & đơn giản và bạn đang đi ngược lại tinh thần của trích dẫn. select *là một mô hình chống.


Vì vậy, chọn cột không phải là một tối ưu hóa sớm. Một vài thứ ngoài đỉnh đầu của tôi ....

  1. Nếu bạn chỉ định các cột trong câu lệnh SQL, công cụ thực thi SQL sẽ báo lỗi nếu cột đó bị xóa khỏi bảng và truy vấn được thực thi.
  2. Bạn có thể dễ dàng quét mã hơn nơi cột đó đang được sử dụng.
  3. Bạn nên luôn luôn viết các truy vấn để mang lại ít thông tin nhất.
  4. Như những người khác đề cập nếu bạn sử dụng truy cập cột thứ tự, bạn không bao giờ nên sử dụng select *
  5. Nếu câu lệnh SQL của bạn tham gia các bảng, hãy chọn * cung cấp cho bạn tất cả các cột từ tất cả các bảng trong phép nối

Hệ quả là sử dụng select *...

  1. Các cột được sử dụng bởi ứng dụng này mờ đục
  2. DBA và trình biên dịch truy vấn của họ không thể giúp hiệu năng kém của ứng dụng của bạn
  3. Mã dễ vỡ hơn khi thay đổi xảy ra
  4. Cơ sở dữ liệu và mạng của bạn đang bị ảnh hưởng vì chúng mang lại quá nhiều dữ liệu (I / O)
  5. Tối ưu hóa công cụ cơ sở dữ liệu là tối thiểu khi bạn mang lại tất cả dữ liệu bất kể (logic).

Viết SQL chính xác cũng dễ như viết Select *. Vì vậy, người lười biếng thực sự viết SQL thích hợp vì họ không muốn xem lại mã và cố gắng nhớ những gì họ đã làm khi họ làm điều đó. Họ không muốn giải thích với DBA về mọi bit mã. Họ không muốn giải thích cho khách hàng của họ tại sao ứng dụng chạy như một con chó.


2
Trong phần đầu tiên của bạn, điểm # 5 sẽ đọc "select * cung cấp cho bạn tất cả các cột từ tất cả các bảng trong liên kết". Trong phần thứ hai của bạn, điểm # 2 và # 5 không nhất thiết đúng và không được liệt kê là lý do để không sử dụng "select *".
jimmyorr

1
@uglysmurf - cảm ơn vì đã sửa, nhưng liên quan đến 2 & 5 - trong khi chúng có thể không nhất thiết đúng với tất cả các cơ sở dữ liệu / dba trong mọi trường hợp, tôi cảm thấy chúng quan trọng và hợp lệ đối với phần lớn các trường hợp và sẽ để chúng vào. Sử dụng 'select *' không bao giờ giúp công việc của dba dễ dàng hơn.
Robert Paulson

11
Tôi tranh luận rằng # 3 (mã giòn) không thực sự đúng. Tùy thuộc vào cách triển khai, Chọn * có thể làm cho nó ÍT HƠN, nhưng tôi không thấy làm thế nào nó có thể hơn thế.
JohnFx

2
@JohnFx, tôi đoán bạn định nghĩa giòn khác nhau. Giòn thường được định nghĩa là "dễ dàng phá vỡ". Có các phụ thuộc không xác định hoặc khó tìm vì mỗi đoạn mã sẽ sử dụng các cột khác nhau có nghĩa là tôi không thể dễ dàng thay đổi bất cứ điều gì ở cấp dữ liệu mà không cần hồi quy đầy đủ .. có vẻ dễ vỡ.
Robert Paulson

9
@mavnn, wrt brittlility, tôi sợ đây là một vấn đề liên quan đến ngữ nghĩa đối với sự lựa chọn của tôi về từ giòn. Lời cuối cùng của tôi là nói rằng nó làm cho ít khác biệt dù sao đi nữa. Kịch bản duy nhất được đổi tên / loại bỏ các cột. Bạn chỉ di chuyển break từ khi sql được thực thi (rõ ràng) so với phá vỡ khi kết quả được tiêu thụ. Cách thức mà kết quả truy vấn được tiêu thụ có thể khác nhau và mã có thể hoặc không âm thầm thất bại, nhưng công cụ thực thi sql chắc chắn sẽ thất bại với sql không hợp lệ. Vì vậy, đã chọn * giúp bạn? IMO thất bại rõ ràng gần hơn với DB cho một vấn đề DB là tốt hơn. Thx
Robert Paulson

42

Nếu mã của bạn phụ thuộc vào các cột theo thứ tự cụ thể, mã của bạn sẽ bị hỏng khi có thay đổi đối với bảng. Ngoài ra, bạn có thể tìm nạp quá nhiều từ bảng khi bạn chọn *, đặc biệt nếu có trường nhị phân trong bảng.

Chỉ vì bạn đang sử dụng tất cả các cột bây giờ, điều đó không có nghĩa là người khác sẽ không thêm một cột vào bảng.

Nó cũng thêm chi phí vào bộ nhớ đệm thực thi kế hoạch vì nó phải tìm nạp dữ liệu meta về bảng để biết các cột nào trong *.


4
Câu trả lời hay, nhưng tôi sẽ thay đổi "mã sẽ phá vỡ" thành "mã CÓ THỂ phá vỡ." Đó là rắc rối thực sự ở đây, việc sử dụng "select *" không LUÔN tạo ra sự thay đổi đột phá. Và khi sự phá vỡ xảy ra thường được phân tách cao từ việc sử dụng kết thúc bị phá vỡ.
BQ.

4
Nếu ai đó đang tham chiếu các cột thông thường trong mã của họ, họ sẽ gặp rắc rối bất kể họ có sử dụng CHỌN * hay không. Chi phí thực hiện kế hoạch là không đáng kể và dù sao đi nữa, kế hoạch sẽ được lưu trữ.
MusiGenesis

1
Sau đó, lỗi lập trình viên nằm ở việc viết mã phụ thuộc vào chuỗi các cột. Bạn không bao giờ cần phải làm điều đó.
dkretz

1
@doofledorfer - không bao giờ nói không bao giờ. Nó nhanh hơn để truy cập các cột thứ tự, và đôi khi nó là thực tế. Đó là một lỗi lớn hơn khi sử dụng select * so với việc sử dụng truy cập thông thường.
Robert Paulson

23

Một lý do chính là nếu bạn từng thêm / xóa các cột khỏi bảng của mình, bất kỳ truy vấn / quy trình nào đang thực hiện cuộc gọi CHỌN * bây giờ sẽ nhận được nhiều hoặc ít cột dữ liệu hơn dự kiến.


3
Bạn không bao giờ nên viết mã phụ thuộc vào số lượng cột được trả lại.
dkretz

4
Nhưng mọi người đều viết mã yêu cầu các lập trình viên biết dữ liệu nào sẽ quay trở lại. Bạn không thể Ctrl + F tên cột của mình nếu nó bị ẩn trong CHỌN *.
Lotus Notes

17
  1. Theo cách vòng, bạn đang phá vỡ quy tắc mô đun về việc sử dụng kiểu gõ nghiêm ngặt bất cứ nơi nào có thể. Rõ ràng là gần như phổ biến tốt hơn.

  2. Ngay cả khi bây giờ bạn cần mọi cột trong bảng, có thể thêm nhiều cột sau sẽ được kéo xuống mỗi khi bạn chạy truy vấn và có thể làm giảm hiệu suất. Nó làm tổn thương hiệu suất vì

    • Bạn đang kéo thêm dữ liệu qua dây; và
    • Bởi vì bạn có thể đánh bại khả năng của trình tối ưu hóa để lấy dữ liệu ra khỏi chỉ mục (đối với các truy vấn trên các cột là một phần của chỉ mục.) Thay vì tự tìm kiếm trong bảng

Khi sử dụng, chọn *

Khi bạn CẦN một cách rõ ràng tất cả các cột trong bảng, trái ngược với việc cần tất cả các cột trong bảng RATNG R EX RÀNG TRONG THỜI GIAN BẠN VIẾT RẤT NHIỀU. Ví dụ: nếu đang viết một ứng dụng quản lý DB cần hiển thị toàn bộ nội dung của bảng (bất kể chúng là gì), bạn có thể sử dụng phương pháp đó.


1
Một lần khác để sử dụng SELECT *sẽ là khi bạn đang thực hiện các truy vấn kiểm tra bằng ứng dụng khách db.
cdmckay

Đó dường như là một ngoại lệ kỳ lạ với bối cảnh của câu hỏi. Khác với việc lưu một số cách gõ, lợi thế của việc này đối với các truy vấn kiểm tra là gì?
JohnFx

Ngoài ra CHỌN * TỪ (CHỌN a, b, c TỪ bảng) là OK.
kmkaplan

12

Có một vài lý do:

  1. Nếu số lượng cột trong cơ sở dữ liệu thay đổi và ứng dụng của bạn hy vọng sẽ có một số lượng nhất định ...
  2. Nếu thứ tự các cột trong cơ sở dữ liệu thay đổi và ứng dụng của bạn hy vọng chúng sẽ theo một thứ tự nhất định ...
  3. Bộ nhớ trên cao. 8 cột INTEGER không cần thiết sẽ thêm 32 byte bộ nhớ bị lãng phí. Điều đó không có vẻ nhiều, nhưng điều này là cho mỗi truy vấn và INTEGER là một trong những loại cột nhỏ ... các cột bổ sung có nhiều khả năng là các cột VARCHAR hoặc TEXT, giúp tăng nhanh hơn.
  4. Mạng trên cao. Liên quan đến chi phí bộ nhớ: nếu tôi phát hành 30.000 truy vấn và có 8 cột INTEGER không cần thiết, tôi đã lãng phí 960kB băng thông. Các cột VARCHAR và TEXT có thể lớn hơn đáng kể.

Lưu ý: Tôi đã chọn INTEGER trong ví dụ trên vì chúng có kích thước cố định là 4 byte.


1 và 2 sẽ là mùi mã và 3 và 4 nghe giống như tối ưu hóa sớm
NikkyD

7

Nếu ứng dụng của bạn lấy dữ liệu với SELECT * và cấu trúc bảng trong cơ sở dữ liệu bị thay đổi (giả sử một cột bị xóa), ứng dụng của bạn sẽ thất bại ở mọi nơi mà bạn tham chiếu trường bị thiếu. Thay vào đó, nếu bạn bao gồm tất cả các cột trong truy vấn của mình, ứng dụng của bạn sẽ ngắt ở (hy vọng) một nơi mà ban đầu bạn nhận được dữ liệu, giúp việc khắc phục dễ dàng hơn.

Điều đó đang được nói, có một số tình huống trong đó CHỌN * là mong muốn. Một là một tình huống mà tôi gặp phải mọi lúc, nơi tôi cần sao chép toàn bộ bảng vào một cơ sở dữ liệu khác (ví dụ như SQL Server sang DB2). Một cái khác là một ứng dụng được viết để hiển thị các bảng một cách khái quát (tức là không có bất kỳ kiến ​​thức nào về bất kỳ bảng cụ thể nào).


Câu hỏi không phải là 'được chọn * bao giờ mong muốn', vì vậy phần thứ 2 trong câu trả lời của bạn là không liên quan. Câu hỏi nói rằng sử dụng 'select *' nên được ưu tiên hơn, tất nhiên đó là các bollocks hoàn chỉnh.
Robert Paulson

Vâng, phần 2 của tôi là không liên quan. OQ đã thay đổi câu hỏi sang trạng thái CHỌN * là thích hợp hơn, và vâng đó là loại bollocksy.
MusiGenesis

Ah yeah xin lỗi - câu hỏi đã thay đổi hướng sau câu trả lời của bạn.
Robert Paulson

Không sao đâu. Ngay cả Mozart cũng là một biên tập viên ( stackoverflow.com/questions/292682/ mài ). Bài viết gốc của tôi cho rằng việc sử dụng CHỌN * dẫn đến ăn thịt người. :)
MusiGenesis

3

Tôi thực sự nhận thấy một hành vi kỳ lạ khi tôi sử dụng select *trong các khung nhìn trong SQL Server 2005.

Chạy truy vấn sau đây và bạn sẽ thấy những gì tôi muốn nói.

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[starTest]') AND type in (N'U'))
DROP TABLE [dbo].[starTest]
CREATE TABLE [dbo].[starTest](
    [id] [int] IDENTITY(1,1) NOT NULL,
    [A] [varchar](50) NULL,
    [B] [varchar](50) NULL,
    [C] [varchar](50) NULL
) ON [PRIMARY]

GO

insert into dbo.starTest
select 'a1','b1','c1'
union all select 'a2','b2','c2'
union all select 'a3','b3','c3'

go
IF  EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[vStartest]'))
DROP VIEW [dbo].[vStartest]
go
create view dbo.vStartest as
select * from dbo.starTest
go

go
IF  EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[vExplicittest]'))
DROP VIEW [dbo].[vExplicittest]
go
create view dbo.[vExplicittest] as
select a,b,c from dbo.starTest
go


select a,b,c from dbo.vStartest
select a,b,c from dbo.vExplicitTest

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[starTest]') AND type in (N'U'))
DROP TABLE [dbo].[starTest]
CREATE TABLE [dbo].[starTest](
    [id] [int] IDENTITY(1,1) NOT NULL,
    [A] [varchar](50) NULL,
    [B] [varchar](50) NULL,
    [D] [varchar](50) NULL,
    [C] [varchar](50) NULL
) ON [PRIMARY]

GO

insert into dbo.starTest
select 'a1','b1','d1','c1'
union all select 'a2','b2','d2','c2'
union all select 'a3','b3','d3','c3'

select a,b,c from dbo.vStartest
select a,b,c from dbo.vExplicittest

So sánh kết quả của 2 câu lệnh chọn cuối cùng. Tôi tin rằng những gì bạn sẽ thấy là kết quả của các cột tham chiếu Chọn * theo chỉ mục thay vì tên.

Nếu bạn xây dựng lại khung nhìn, nó sẽ hoạt động tốt trở lại.

BIÊN TẬP

Tôi đã thêm một câu hỏi riêng, * Chọn chọn * từ bảng Trực so với chọn colA, colB, v.v. từ bảng Hành vi thú vị của bảng trong SQL Server 2005 * để xem xét chi tiết hành vi đó.


2

Bạn có thể nối hai bảng và sử dụng cột A từ bảng thứ hai. Nếu sau này bạn thêm cột A vào bảng đầu tiên (có cùng tên nhưng có thể có ý nghĩa khác nhau) thì rất có thể bạn sẽ nhận được các giá trị từ bảng đầu tiên chứ không phải là bảng thứ hai như trước đó. Điều đó sẽ không xảy ra nếu bạn chỉ định rõ ràng các cột bạn muốn chọn.

Tất nhiên việc chỉ định các cột đôi khi cũng gây ra lỗi nếu bạn quên thêm các cột mới vào mỗi mệnh đề chọn. Nếu cột mới không cần thiết mỗi khi truy vấn được thực thi, có thể mất một thời gian trước khi lỗi được chú ý.


2

Tôi hiểu bạn đang đi đâu về tối ưu hóa sớm, nhưng điều đó thực sự chỉ đi đến một điểm. Mục đích là để tránh tối ưu hóa không cần thiết ngay từ đầu. Có phải bảng của bạn không được lập trình? Bạn có sử dụng nvarchar (4000) để lưu trữ mã zip không?

Như những người khác đã chỉ ra, có những điểm tích cực khác để chỉ định từng cột bạn định sử dụng trong truy vấn (chẳng hạn như khả năng duy trì).


2

Khi bạn chỉ định các cột, bạn cũng tự buộc mình vào một nhóm cột cụ thể và khiến bản thân trở nên kém linh hoạt hơn, khiến Feuerstein lăn lộn, bất kể anh ấy ở đâu. Chỉ là một ý nghĩ.


1
Tôi hoàn toàn không biết Feuerstein là ai. Đã thử googling và tìm thấy một nhà tâm lý học, một nhân vật truyền hình và một blogger để điều tốt nhất tôi có thể nghĩ ra là một trò đùa.
NotMe

Tác giả của các cuốn sách O'Reilly về PL / SQL. Hãy thử googling "feuerstein sql" thay vì chỉ "feuerstein".
orbfish

2

CHỌN * không phải lúc nào cũng xấu. Theo tôi, ít nhất. Tôi sử dụng nó khá thường xuyên cho các truy vấn động trả về toàn bộ bảng, cộng với một số trường được tính toán.

Chẳng hạn, tôi muốn tính toán hình học địa lý từ một bảng "bình thường", đó là một bảng không có bất kỳ trường hình học nào, nhưng với các trường có chứa tọa độ. Tôi sử dụng postgresql và postgis mở rộng không gian của nó. Nhưng nguyên tắc áp dụng cho nhiều trường hợp khác.

Một ví dụ:

  • một bảng địa điểm, với tọa độ được lưu trữ trong các trường có nhãn x, y, z:

    TẠO các vị trí BẢNG (số nguyên Place_id, x số (10, 3), y số (10, 3), z số (10, 3), mô tả varchar);

  • hãy cho nó ăn với một vài giá trị mẫu:

    XÁC NHẬN VÀO các địa điểm (place_id, x, y, z, mô tả) GIÁ TRỊ
    (1, 2.295, 48.863, 64, 'Paris, Place de l \' Étoile '),
    (2, 2.945, 48.858, 40,' Paris, Tour Eiffel '),
    (3, 0,373, 43.958, 90,' Bao cao su, Cathédrale St-Pierre ');

  • Tôi muốn có thể ánh xạ nội dung của bảng này, sử dụng một số máy khách GIS. Cách thông thường là thêm trường hình học vào bảng và xây dựng hình học, dựa trên tọa độ. Nhưng tôi muốn nhận được một truy vấn động: theo cách này, khi tôi thay đổi tọa độ (hiệu chỉnh, độ chính xác hơn, v.v.), các đối tượng được ánh xạ thực sự di chuyển, một cách linh hoạt. Vì vậy, đây là truy vấn với CHỌN * :

    TẠO HOẶC THAY THẾ XEM địa điểm_ điểm NHƯ
    CHỌN *,
    GeomFromewkt ('SRID = 4326; ĐIỂM (' | | x | | '' | | y | | '' | | z || ')')
    TỪ các địa điểm;

    Tham khảo postgis, để sử dụng hàm GeomFromewkt ().

  • Đây là kết quả:

    CHỌN * TỪ địa điểm;

nơi_id | x | y | z | mô tả | geomfromewkt                            
---------- + ------- + -------- + -------- + ------------- ----------------- + -------------------------------- ------------------------------------  
        1 | 2,295 | 48.863 | 64.000 | Paris, Place de l'Étoile | 01010000A0E61000005C8FC2F5285C02405839B4C8766E48400000000000005040  
        2 | 2.945 | 48.858 | 40.000 | Paris, Tour Eiffel | 01010000A0E61000008FC2F5285C8F0740E7FBA9F1D26D48400000000000004440
        3 | 0,373 | 43.958 | 90.000 | Bao cao su, Cathédrale St-Pierre | 01010000A0E6100000AC1C5A643BDFD73FB4C876BE9FFA45400000000000805640
(3 lign)

Cột ngoài cùng bên phải bây giờ có thể được sử dụng bởi bất kỳ chương trình GIS nào để ánh xạ chính xác các điểm.

  • Nếu trong tương lai, một số trường được thêm vào bảng: không phải lo lắng, tôi chỉ phải chạy lại định nghĩa XEM tương tự.

Tôi muốn định nghĩa của VIEW có thể được giữ nguyên "như hiện tại", với *, nhưng hélas không phải là trường hợp này: đây là cách nó được lưu trữ nội bộ bởi postgresql:

CHỌN địa điểm.place_id, địa điểm.x, địa điểm.y, địa điểm.z, địa điểm.des mô tả, geomfromewkt ((((((('SRID = 4326; POINT (' :: text | | nơi.x) || '': : văn bản) | | địa điểm.y) || '' :: văn bản) | | địa điểm.z) || ')' :: văn bản) NHƯ geomfromewkt TỪ địa điểm;


1

Ngay cả khi bạn sử dụng mọi cột nhưng giải quyết mảng hàng theo chỉ số số, bạn sẽ gặp vấn đề nếu bạn thêm một hàng khác sau này.

Vì vậy, về cơ bản nó là một câu hỏi về khả năng bảo trì! Nếu bạn không sử dụng bộ chọn *, bạn sẽ không phải lo lắng về các truy vấn của mình.


1

Chỉ chọn các cột bạn cần giữ cho tập dữ liệu trong bộ nhớ nhỏ hơn và do đó giữ cho ứng dụng của bạn nhanh hơn.

Ngoài ra, rất nhiều công cụ (ví dụ như các thủ tục được lưu trữ) cũng có kế hoạch thực hiện truy vấn bộ đệm. Nếu sau này bạn thêm hoặc xóa một cột (đặc biệt dễ dàng nếu bạn chọn tắt chế độ xem), công cụ sẽ thường bị lỗi khi không nhận được kết quả mà nó mong đợi.


1

Nó làm cho mã của bạn mơ hồ hơn và khó bảo trì hơn; bởi vì bạn đang thêm dữ liệu không được sử dụng vào tên miền và không rõ bạn dự định và không. (Nó cũng gợi ý rằng bạn có thể không biết hoặc không quan tâm.)


1

Để trả lời câu hỏi của bạn trực tiếp: Không sử dụng "CHỌN *" khi mã này làm cho mã của bạn trở nên yếu hơn khi thay đổi các bảng bên dưới. Mã của bạn chỉ bị phá vỡ khi một thay đổi được thực hiện đối với bảng có ảnh hưởng trực tiếp đến các yêu cầu của chương trình của bạn.

Ứng dụng của bạn nên tận dụng lớp trừu tượng mà truy cập quan hệ cung cấp.


1

Tôi không sử dụng CHỌN * đơn giản vì thật tuyệt khi thấy và biết những lĩnh vực nào tôi đang truy xuất.


1

Nói chung là không tốt khi sử dụng 'select *' bên trong các chế độ xem vì bạn sẽ buộc phải biên dịch lại chế độ xem trong trường hợp thay đổi cột bảng. Thay đổi các cột trong bảng của chế độ xem, bạn sẽ gặp lỗi cho các cột không tồn tại cho đến khi bạn quay lại và biên dịch lại.


1

Sẽ ổn khi bạn làm exists(select * ...)vì nó không bao giờ được mở rộng. Mặt khác, nó thực sự chỉ hữu ích khi khám phá các bảng có các lựa chọn tạm thời hoặc nếu bạn có CTE được xác định ở trên và bạn muốn mọi cột mà không cần gõ lại tất cả chúng.


1

Chỉ cần thêm một điều mà không ai khác đã đề cập. Select *trả về tất cả các cột, ai đó có thể thêm một cột sau mà bạn không nhất thiết muốn người dùng có thể xem như ai cập nhật dữ liệu lần cuối hoặc dấu thời gian hoặc ghi chú mà chỉ người quản lý mới nhìn thấy không phải tất cả người dùng, v.v.

Hơn nữa, khi thêm một cột, tác động lên mã hiện tại cần được xem xét và xem xét để xem có cần thay đổi hay không dựa trên thông tin nào được lưu trữ trong cột. Bằng cách sử dụng select *, đánh giá đó thường sẽ bị bỏ qua vì nhà phát triển sẽ cho rằng không có gì sẽ phá vỡ. Và trên thực tế, không có gì rõ ràng có thể bị phá vỡ nhưng các truy vấn có thể bắt đầu trả lại điều sai. Chỉ vì không có gì phá vỡ rõ ràng, không có nghĩa là không nên có thay đổi đối với các truy vấn.


0

bởi vì "select *" sẽ lãng phí bộ nhớ khi bạn không cần tất cả các trường. Nhưng đối với máy chủ sql, hiệu suất của chúng là như nhau.

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.