Tối ưu hóa câu truy vấn giúp website bạn chạy nhanh hơn và ổn định hơn với lượng truy cập lớn. Kinh nghiệm lập trình và tối ưu hóa câu truy vấn trong MySQLThân chào các bạn Lập Trình Web! Trong sự nghiệp lập trình web của mình, hẳn không ít coder chúng ta không có những mục tiêu, hoài bão là xây dựng, thực hiện được những dự án lớn, có tầm cỡ quốc gia, quốc tế. Chẳng hạn Vật Giá, Chợ Điện Tử, Zing, Zooz... ở Việt Nam, hay lớn hơn là những YouTube, MySpace,
facebook... trên qui mô toàn cầu. Khi nói đến những dự án lớn thì một trong những vấn đề được các coder quan tâm hàng đầu đó là hiệu suất của dự án. Một site nhỏ với qui mô vài trăm user, dung lượng database chưa đáng kể thì thời gian truy vấn, tải trang chưa phải là vấn đề bạn cần quan tâm. Nhưng theo thời gian site phát triển với tốc độ chóng mặt, chẳng mấy chốc đã có tới hàng triệu users tham gia, tỉ lệ thuận với nó là bảng users có hàng triệu records, database phình to, dung lượng có thể lên đến hàng gigabyte, hàng chục gigabyte thậm chí hàng trăm gigabyte... :ohmy: Lúc này, ngoài việc triển khai các kế hoạch kinh doanh, khai thác lợi nhuận (có thể để bộ phận kinh doanh lo) thì một vấn đề lớn đặt ra cho các coder chúng ta là làm sao để website với 1 database to như vậy vẫn chạy mượt mà như là database nhỏ!? Ngoài những vấn đề về đầu tư cơ sở hạ tầng khủng với server cấu hình cao, database server riêng rẽ, chuẩn hóa code ra mình mạo muội viết bài viết này để chúng ta cùng chia sẽ những kinh nghiệm, thủ thuật về tối ưu truy vấn
MySQL với một database lớn. Mình xin bắt đầu với 1 database có bảng users với khoảng 1 triệu records, nó là kinh nghiệm mình gặt hái được trong quá trình tham gia phát triển dự án game online UGH!
* Thủ thuật 1: INSERT
- Ngữ cảnh: chúng ta có 2 bảng users (1 triệu records), messages (empty) với cấu trúc: users
- user_id - name - money
messages
- message_id - user_id - subject - body
- Yêu cầu: một ngày đẹp trời, bạn muốn gửi thông điệp đến tất cả các users có số money ít hơn 1 USD rằng: Tai khoan cua ban sap het! Hay nop them tien vao tai khoan. - Cách làm thông thường:
CODE
$query = MySQL_query("SELECT * FROM users WHERE money < 1"); $subject = "Money cua ban sap het!"; while ( $row = db_fetch_object($query) ) { $body = $row->name ." than men! So money trong tai khoan cua ban chi con chua den 1 USD - mua duoc 1 kg rau muong luoc. Hay nop them tien vao tai khoan de giao dich khong bi gian doan."; MySQL_query("INSERT INTO messages (user_id, subject, body) VALUES ($row->user_id, '$subject', '$body')"); } // Processed in 67.0436019897 sec
=> Cách làm tối ưu: dùng 1 query để giải quyết tình huống này
CODE
MySQL_query(" INSERT INTO messages (user_id, subject, body) SELECT user_id, 'Money cua ban sap het!', CONCAT(name, ' than men! So money trong tai khoan cua ban chi con chua den 1 USD - mua duoc 1 kg rau muong luoc. Hay nop them tien vao tai khoan de giao dich khong bi gian doan.') FROM users WHERE money < 1 "); // Processed in: 3.5900 sec
Kết quả: thời gian xử lí giảm xuống gần 20 lần Thủ thuật trong trường hợp này: - Kết hợp INSERT và SELECT để thay thế cho while của PHP. - Dùng CONCAT để lấy name của user.
* Thủ thuật 2: UPDATE
- Ngữ cảnh: có 2 bảng users (1 triệu records), user_scores (2 triệu records) users
- user_id - name - total_scores - max_scores_can_contain
user_scores
- user_score_id - user_id - score_type_id - scores
- Yêu cầu: một user sẽ được cộng thêm 1 số điểm là scores trong bảng user_scores tương ứng với mỗi score_type_id (ưu tiên theo score_type_id) mà user đang có. Nhưng tổng số scores hiện có và scores của các score_type_id này không được vượt quá con số max_scores_can_contain trong bảng users, nếu vượt quá thì chỉ lấy số scores tương ứng với tổng số scores bằng max_scores_can_contain. Sao yêu cầu loằng ngoằng vậy ta :innocent:? Chắc do nó là advanced nên mới thế :emlaugh:. - Giải quyết vấn đề:
CODE
// Query tat ca users, chi update nhung user co scores > 0 $query = MySQL_query("SELECT * FROM user_scores WHERE scores > 0"); while ( $row = MySQL_fetch_object($query) ) { // Lay object cua user nay $user = MySQL_fetch_object(MySQL_query("SELECT * FROM users WHERE user_id = $row->user_id")); // Chi cong nhung user cos total_scores < max_scores_can_contain if ( $user->total_scores < $user->max_scores_can_contain ) { // Bat dau kiem tra bien scores_addition se cong vao if ( $user->total_scores + $row->scores >= $user->max_scores_can_contain ) { // Chi cong vao de total scores = max scores can contain $scores_addition = $user->max_scores_can_contain - $user->total_scores; } else { // Cong binh thuong $scores_addition = $row->scores; } // Bat dau cong MySQL_query("UPDATE users SET total_scores = total_scores + $scores_addition WHERE user_id = $user->user_id"); } } // Processed in 530.916620016 sec
=> Tối ưu:
CODE
MySQL_query(" UPDATE users AS u LEFT JOIN user_scores AS us ON u.user_id = us.user_id SET u.total_scores = u.total_scores + ( CASE WHEN (u.total_scores + us.scores) > u.max_scores_can_contain THEN (u.max_scores_can_contain - u.total_scores) ELSE us.scores END ) WHERE u.total_scores < u.max_scores_can_contain AND us.scores > 0 "); // Processed in 59.2287611961 sec
Kết quả: thời gian xử lí giảm đi gần 10 lần. Chúc các bạn học tốt
Phần đọc thêm CODE
1. Paging/chunked data retrieval to limit
2. Don’t use SELECT *
3. Be wary of lots of small quick queries if a longer query can be more efficient
+ Use EXPLAIN to profile the query execution plan
+ Use Slow Query Log (always have it on!)
+ Don’t use DISTINCT when you have or could use GROUP BY
+ Use proper data partitions
1. For Cluster. Start thinking about Cluster *before* you need them
+ Insert performance
1. Batch INSERT and REPLACE
2. Use LOAD DATA instead of INSERT
+ LIMIT m,n may not be as fast as it sounds
+ Don’t use ORDER BY RAND() if you have > ~2K records
+ Use SQL_NO_CACHE when you are SELECTing frequently updated data or large sets of data
+ avoid wildcards at the start of LIKE queries
+ avoid correlated subqueries and in select and where clause (try to avoid in)
+ config params –
+ no calculated comparisons — isolate indexed columns
+ innodb_flush_commit=0 can help slave lag
+ ORDER BY and LIMIT work best with equalities and covered indexes
+ isolate workloads don’t let administrative work interfere with customer performance. (ie backups)
+ use optimistic locking, not pessimistic locking. try to use shared lock, not exclusive lock. share mode vs. FOR UPDATE
+ use row-level instead of table-level locking for OLTP workloads
+ Know your storage engines and what performs best for your needs, know that different ones exist.
1. use MERGE tables ARCHIVE tables for logs
+ Optimize for data types, use consistent data types. Use PROCEDURE ANALYSE() to help determine if you need less
+ separate text/blobs from metadata, don’t put text/blobs in results if you don’t need them
+ if you can, compress text/blobs
+ compress static data
+ don’t back up static data as often
+ derived tables (subqueries in the FROM clause) can be useful for retrieving BLOBs w/out sorting them. (self-join can speed up a query if 1st part finds the IDs and use it to fetch the rest)
+ enable and increase the query and buffer caches if appropriate
+ ALTER TABLE…ORDER BY can take chronological data and re-order it by a different field
+ InnoDB ALWAYS keeps the primary key as part of each index, so do not make the primary key very large, be careful of redundant columns in an index, and this can make the query faster
+ Do not duplicate indexes
+ Utilize different storage engines on master/slave ie, if you need fulltext indexing on a table.
+ BLACKHOLE engine and replication is much faster than FEDERATED tables for things like logs.
+ Design sane query schemas. don’t be afraid of table joins, often they are faster than denormalization
+ Don’t use boolean flags
+ Use a clever key and ORDER BY instead of MAX
+ Keep the database host as clean as possible. Do you really need a windowing system on that server?
+ Utilize the strengths of the OS
+ Hire a MySQL ™ Certified DBA
+ Know that there are many consulting companies out there that can help, as well as MySQL’s Professional Services.
+ Config variables & tips:
1. use one of the supplied config files
2. key_buffer, unix cache (leave some RAM free), per-connection variables, innodb memory variables
3. be aware of global vs. per-connection variables
4. check SHOW STATUS and SHOW VARIABLES (GLOBAL|SESSION in 5.0 and up)
5. be aware of swapping esp. with Linux, “swappiness” (bypass OS filecache for innodb data files, innodb_flush_method=O_DIRECT if possible (this is also OS specific))
6. defragment tables, rebuild indexes, do table maintenance
7. If you use innodb_flush_txn_commit=1, use a battery-backed hardware cache write controller
8. more RAM is good so faster disk speed
9. use 64-bit architectures
+ Know when to split a complex query and join smaller ones
+ Debugging sucks, testing rocks!
+ Delete small amounts at a time if you can
+ Archive old data — don’t be a pack-rat! 2 common engines for this are ARCHIVE tables and MERGE tables
+ use INET_ATON and INET_NTOA for IP addresses, not char or varchar
+ make it a habit to REVERSE() email addresses, so you can easily search domains
+ –skip-name-resolve
+ increase myisam_sort_buffer_size to optimize large inserts (this is a per-connection variable)
+ look up memory tuning parameter for on-insert caching
+ increase temp table size in a data warehousing environment (default is 32Mb) so it doesn’t write to disk (also constrained by max_heap_table_size, default 16Mb)
+ Normalize first, and denormalize where appropriate.
+ Databases are not spreadsheets, even though Access really really looks like one. Then again, Access isn’t a real database
+ In 5.1 BOOL/BIT NOT NULL type is 1 bit, in previous versions it’s 1 byte.
+ A NULL data type can take more room to store than NOT NULL
+ Choose appropriate character sets & collations — UTF16 will store each character in 2 bytes, whether it needs it or not, latin1 is faster than UTF8.
+ make similar queries consistent so cache is used
+ Have good SQL query standards
+ Don’t use deprecated features
+ Use Triggers wisely
+ Run in SQL_MODE=STRICT to help identify warnings
+ Turning OR on multiple index fields (<5.0) into UNION may speed things up (with LIMIT), after 5.0 the index_merge should pick stuff up.
+ /tmp dir on battery-backed write cache
+ consider battery-backed RAM for innodb logfiles
+ use min_rows and max_rows to specify approximate data size so space can be pre-allocated and reference points can be calculated.
+ as your data grows, indexing may change (cardinality and selectivity change). Structuring may want to change. Make your schema as modular as your code. Make your code able to scale. Plan and embrace change, and get developers to do the same.
+ pare down cron scripts
+ create a test environment
+ try out a few schemas and storage engines in your test environment before picking one.
+ Use HASH indexing for indexing across columns with similar data prefixes
+ Use myisam_pack_keys for int data
+ Don’t use COUNT * on Innodb tables for every search, do it a few times and/or summary tables, or if you need it for the total + of rows, use SQL_CALC_FOUND_ROWS and SELECT FOUND_ROWS()
+ use –safe-updates for client
+ Redundant data is redundant
+ Use INSERT … ON DUPLICATE KEY update (INSERT IGNORE) to avoid having to SELECT
+ use groupwise maximum instead of subqueries
+ be able to change your schema without ruining functionality of your code
+ source control schema and config files
+ for LVM innodb backups, restore to a different instance of MySQL so Innodb can roll forward
+ use multi_query if appropriate to reduce round()-trips
+ partition appropriately
+ partition your database when you have real data
+ segregate tables/databases that benefit from different configuration variables
(http://www.miendatweb.com/home/post-toi-uu-hoa-truy-van-mysql-cho-site-co-luong-truy-cap-lon-323.html)
