thắc mắc Cách tối ưu query cho query sql?
- Thread starter thaihiep
- Start date
De Koning
Senior Member
pls don't, it's another bad coding practiceNếu muốn làm triệt để hài hòa cả performance lẫn clean code thì câu query mẫu có thể có input là list các field muốn query, mỗi feature nào cần dùng sẽ tự truyền các field mình muốn lấy, vẫn thỏa điều kiện phần code build query gốc không thay đổi
thanpaint01
Junior Member
Đó là lười biếng không phải là cleancodeMình lại ủng hộ select * vì có thể tái sử dụng câu sql này cho nhiều api cần các field khác nhau, mỗi api sẽ tự transform để lấy 1 số field nó cần, và câu sql gốc không cần chỉnh sửa, thêm bớt field
))), cleancode dễ đọc và dễ maintain cái select * chả được đạt cái nào ỏ trong cái đó cả. Thậm chí bác chẳng biết lấy chính lý luận của Uncle Bob, là small code của ổng để lý luận thì có lẽ bác chả biết tí gì về cleancode r
ngolebaotrung
Senior Member
Nếu thế thì tha viết raw query còn tốt hơn, còn phải thêm where, order ... nữa mà.Nếu muốn làm triệt để hài hòa cả performance lẫn clean code thì câu query mẫu có thể có input là list các field muốn query, mỗi feature nào cần dùng sẽ tự truyền các field mình muốn lấy, vẫn thỏa điều kiện phần code build query gốc không thay đổi
Mazda Support
Member
thực ra dùng ORM thì làm gì có cơ hội nó sinh ra câu query 'select *' mà lo
thanhtplxag
Senior Member
Làm project đó giờ toàn dùng ORM cảm giác bị mù về món SQL này
Love U So Much
Senior Member
Đúng rồi bạn. Kể cả 2 use case có query giống nhau cũng viết 2 câu. Vì nếu sau này 1use case thay đổi thì sửa nó ko bị sai use case khácMình cũng khá mù mờ về vụ này, vậy các thím giải quyết như thế nào nhỉ
De Koning
Senior Member
Nếu muốn làm triệt để hài hòa cả performance lẫn clean code thì câu query mẫu có thể có input là list các field muốn query, mỗi feature nào cần dùng sẽ tự truyền các field mình muốn lấy, vẫn thỏa điều kiện phần code build query gốc không thay đổi
Nếu app code mà được tuỳ biến fields trong query đến DB thì quá nhiều rủi ro về security như SQL injection, expose những field cần bảo mật vì tôi đoán để dựng lại query với input fields thím sẽ dùng CONCAT. Thím hãy coi DB là 1 service như các service bình thường khác, data whitelisting chứ không phải blacklisting.
Nhưng vấn đề lớn hơn sẽ là performance. Không biết các RDBMS khác thế nào, nhưng với MySQL hoặc MariaDB, nếu các fields là variable thì câu query sẽ không được lên execution plan và optimize, index bị bỏ qua và worst case sẽ là full table scan.
Trong API, nói chung mỗi method nên dùng 1 query riêng. Thím có thể xem xét dùng chung query cho các version khác nhau của cùng 1 method và các version phải backward compatibleMình cũng khá mù mờ về vụ này, vậy các thím giải quyết như thế nào nhỉ
De Koning
Senior Member
Nói mới nhớ, cách đây mấy năm tôi đã phải maintain 1 con stored procedure khoảng 1500 lines. Sau quyết định đập đi hết, chuyển logic vào java code.
pipoi qwewe
Member
CodeFirst chỉ áp dụng cho C# thôi hả bạn. Có áp dụng cho NodeJs, PHP, Java được không ạ.
Web.Coder
Senior Member
Cái này chắc để ae dev khác confirm. Do mình coder trái ngành nên xác định gắn chặt với hệ sinh thái .NET rồi chưa có cơ hội đụng với các ngôn ngữ backend khác.
chungvodim1
Senior Member
- Index => OK, nhưng nhớ xài execution plan để biết cái j cần index
- NoLock => Có chắc là bạn cần nolock không. Nếu chấp nhận dirty data thì xài NoLock.
- Tránh viết câu phức tạp. Tốt nhất là xài Execution Plan để biết cái phần nào của query tốn nhiều cost.
- SP sẽ khó maintain.
- Nên Xài Limit
- Xài Partition (Partition theo zone hoặc theo datetime)
Last edited:
kangtk
Senior Member
TypeOrm nếu không select field thì sẽ sinh rathực ra dùng ORM thì làm gì có cơ hội nó sinh ra câu query 'select *' mà lo
select *
De Koning
Senior Member
Bình thường với ORM, thím check performance như thế nào? Tìm câu query do framework generate ra trong log rồi chạy thử manually à?
Web.Coder
Senior Member
Em chỉ làm mấy hệ thống nhỏ và không đòi hỏi cao nên chưa check performance kỹ bao giờ bác à. Em test ở localhost nếu response của API trả về < 300 ms là đối với em nó ok rồi
chungvodim1
Senior Member
Nên làm stress test để tìm bottleneck.Em chỉ làm mấy hệ thống nhỏ và không đòi hỏi cao nên chưa check performance kỹ bao giờ bác à. Em test ở localhost nếu response của API trả về < 300 ms là đối với em nó ok rồi
De Koning
Senior Member
Nói thím đừng buồn chứ test và optimize DB perf trên localhost, data không đủ lớn mà lại gọi qua API thì gần như là vô nghĩa.Em chỉ làm mấy hệ thống nhỏ và không đòi hỏi cao nên chưa check performance kỹ bao giờ bác à. Em test ở localhost nếu response của API trả về < 300 ms là đối với em nó ok rồi
Trước tôi có maintain 1 dự án doctrine 1 thời gian, phải tìm câu query trong log rồi chạy manually trên DB để xem perf như thế nào, đặt index ở đâu cho hợp lý.
codeforfood2015
Member
100m bản ghi mà cứ 1k thì bao giờ mới xongLớn thì cũng nên batch processing chứ nhỉ, kéo từng lô 1000 records ra xử lý xong lấy lô khác, chứ lấy hết lên rồi mới đẩy đi thì RAM đâu cho đủ
)Similar threads
