搜尋
首頁後端開發php教程一个有关MYSQL的文章.E文的.MySQLs Query Cache_PHP教程


http://www.discuz.net/viewthread.php?tid=43137&sid=G4jizDNovember 18, 2003MySQLs Query CacheBy Ian GilfillanA typical scenarioBoss: Our new website is crawling! How can it be, we have four state-of-the-art web servers - whats the problem?You: Well, the web servers are fine - its the database server thats struggling.Boss: What? You told me this MySQL thing was fast, that we didnt need Oracle, and now you say it cant cope! How can this be?You: Well, the web servers are behaving so well that theyre pushing through lots of queries, and the database cant manage to process all of them at the same time. Its only one database, and lots of web servers...Boss: Its too late to buy Oracle now - what are we going to do!?Big Boss to Boss(in the bosss mind): This project has been a disaster from the beginning - now you want me to delay it while we install a new database, and spend a whole lot more! Do you think were made of money!? Im calling in someone who knows what theyre doing - youre history buddy.Colleague (about to take your job): Wait, I think I can solve the problem!So, what does your colleague know that you dont? How can he save the day and let the boss get all the credit? Our scenario is too imprecise to generalize, and there are many possible solutions. You can read about optimizing queries and indexes, optimizing by improving the hardware, and tweaking the MySQL variables, using the slow query log, and of course, there are other methods such as replication. However, MySQL 4 provides one feature that can prove very handy - a query cache. In a situation where the database has to repeatedly run the same queries on the same data set, returning the same results each time, MySQL can cache the result set, avoiding the overhead of running through the data over and over. Usually, you would want to implement some sort of caching on the web server, but there are times when this is not possible, and then it is the query cache you will look to for help.Setting up the query cacheTo make sure MySQL uses the query cache, there are a few variables you need to set in the configuration file (usually my.cnf or my.ini). First, is the query_cache_type. There are three possible settings: 0 (for off, do not use), 1 (for on, cache queries) and 2 (on demand, discussed more below). To ensure it is always on, place: query-cache-type = 1in the configuration file. If you started the server having only made this change, you would see the following cache variables set: mysql> SHOW VARIABLES LIKE %query_cache%;+-------------------+---------+| Variable_name | Value |+-------------------+---------+| have_query_cache | YES || query_cache_limit | 1048576 || query_cache_size | 0 || query_cache_type | ON |+-------------------+---------+4 rows in set (0.06 sec)Note that these are results from MySQL 4.0.x - youll see more in versions 4.1.x and beyond. The query_cache_type will be set to ON or OFF as appropriate. However, there is one more to set, and that is the query_cache_size. If set to 0 (the default), the cache will be disabled. This variable determines the memory, in bytes, used for the query cache. For our purposes, we will set it to 20 MB: query-cache-size = 20MThe amount is shown in bytes: mysql> SHOW VARIABLES LIKE %query_cache%;+-------------------+----------+| Variable_name | Value |+-------------------+----------+| have_query_cache | YES || query_cache_limit | 1048576 || query_cache_size | 20971520 || query_cache_type | ON |+-------------------+----------+4 rows in set (0.06 sec)The Query cache in action (almost)For this tutorial, I used a dump from Wikipedia, the open content encyclopedia (you can find the dumps here. I am using a fairly slow machine, with nothing else happening on it, to minimize interference in the results. Lets run the same query twice, and see how much improvement we see the second time: SELECT * FROM cur;...14144 rows in set (2.96 sec)Now we run the same query again: SELECT * FROM cur; 14144 rows in set (3.02 sec) Now we run the same query again: SELECT * FROM cur; 14144 rows in set (3.02 sec) What is happening? We would expect the second query to take noticeably less time. Lets examine some of the status variables to get a better picture. mysql> SHOW STATUS LIKE %qcache%;+-------------------------+----------+| Variable_name | Value |+-------------------------+----------+| Qcache_queries_in_cache | 0 || Qcache_inserts | 2 || Qcache_hits | 0 || Qcache_lowmem_prunes | 0 || Qcache_not_cached | 2 || Qcache_free_memory | 20962720 || Qcache_free_blocks | 1 || Qcache_total_blocks | 1 |+-------------------------+----------+8 rows in set (0.00 sec)The two queries we ran are both recorded (by Qcache_inserts), but neither of them have been cached. (You may get different results if other queries have been running.) The problem is that the result set is too big. I used the Wikipedia Esperanto dump (4MB compressed - the English dump is 135MB, and even though my English is better than my Esperanto, bandwidth is expensive in South Africa!), but it is immaterial, as even that is more than the query cache can handle by default. There are two limits in play here - the limit for each individual query is determined by the value of query_cache_limit, which is 1MB by default. Moreover, the limit of the cache in total is determined by query_cache_size, which we have seen already. The former limit applies here. If a result set is greater than 1M, it is not cached. The Query cache in action (really)Lets try a smaller query: SELECT cur_is_new FROM cur WHERE cur_user_text > Y...2336 rows in set (0.38 sec)Lets see if this one was cached:mysql> SHOW STATUS LIKE %qcache%;+-------------------------+----------+| Variable_name | Value |+-------------------------+----------+| Qcache_queries_in_cache | 1 || Qcache_inserts | 3 || Qcache_hits | 0 || Qcache_lowmem_prunes | 0 || Qcache_not_cached | 2 || Qcache_free_memory | 20947592 || Qcache_free_blocks | 1 || Qcache_total_blocks | 4 |+-------------------------+----------+8 rows in set (0.00 sec)There is now a query in the cache. If it took 0.38 seconds to run the first time, lets see if we notice an improvement the second time: SELECT cur_is_new FROM cur WHERE cur_user_text > Y...2336 rows in set (0.11 sec)Much better! And, looking at the status again: mysql> SHOW STATUS LIKE %qcache%;+-------------------------+----------+| Variable_name | Value |+-------------------------+----------+| Qcache_queries_in_cache | 1 || Qcache_inserts | 3 || Qcache_hits | 1 || Qcache_lowmem_prunes | 0 || Qcache_not_cached | 2 || Qcache_free_memory | 20947592 || Qcache_free_blocks | 1 || Qcache_total_blocks | 4 |+-------------------------+----------+8 rows in set (0.06 sec)The cache has been hit once. The status variables above should be fairly self-explanatory. Available memory for the cache has gone from 20962720 to 20947592 bytes. The most useful variable for future tuning is Qcache_lowmem_prunes. Each time a cached query is removed from the query cache, (because MySQL needs to make space for another), this value will be incremented. If it increases quickly, and you still have memory to spare, you can up the query_cache_size, while if it never increases, you can reduce the cache size. Lets run the query again, with a slight difference, as follows: SELECT cur_is_new from cur where cur_user_text > Y...2336 rows in set (0.33 sec)That took longer than we would have expected. Lets look at the status variables to see whats up: mysql> SHOW STATUS LIKE %qcache%;+-------------------------+----------+| Variable_name | Value |+-------------------------+----------+| Qcache_queries_in_cache | 2 || Qcache_inserts | 4 || Qcache_hits | 1 || Qcache_lowmem_prunes | 0 || Qcache_not_cached | 2 || Qcache_free_memory | 20932976 || Qcache_free_blocks | 1 || Qcache_total_blocks | 6 |+-------------------------+----------+The query has not made use of the cache - in fact, MySQL has inserted another query in the cache! The proble

www.bkjia.comtruehttp://www.bkjia.com/PHPjc/531868.htmlTechArticlehttp://www.discuz.net/viewthread.php?tid=43137+-------------------+---------+| Variable_name | Value |+-------------------+---------+| have_query_cache | YES || query_cache_limit |...
陳述
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
使用數據庫存儲會話的優點是什麼?使用數據庫存儲會話的優點是什麼?Apr 24, 2025 am 12:16 AM

使用數據庫存儲會話的主要優勢包括持久性、可擴展性和安全性。 1.持久性:即使服務器重啟,會話數據也能保持不變。 2.可擴展性:適用於分佈式系統,確保會話數據在多服務器間同步。 3.安全性:數據庫提供加密存儲,保護敏感信息。

您如何在PHP中實現自定義會話處理?您如何在PHP中實現自定義會話處理?Apr 24, 2025 am 12:16 AM

在PHP中實現自定義會話處理可以通過實現SessionHandlerInterface接口來完成。具體步驟包括:1)創建實現SessionHandlerInterface的類,如CustomSessionHandler;2)重寫接口中的方法(如open,close,read,write,destroy,gc)來定義會話數據的生命週期和存儲方式;3)在PHP腳本中註冊自定義會話處理器並啟動會話。這樣可以將數據存儲在MySQL、Redis等介質中,提升性能、安全性和可擴展性。

什麼是會話ID?什麼是會話ID?Apr 24, 2025 am 12:13 AM

SessionID是網絡應用程序中用來跟踪用戶會話狀態的機制。 1.它是一個隨機生成的字符串,用於在用戶與服務器之間的多次交互中保持用戶的身份信息。 2.服務器生成並通過cookie或URL參數發送給客戶端,幫助在用戶的多次請求中識別和關聯這些請求。 3.生成通常使用隨機算法保證唯一性和不可預測性。 4.在實際開發中,可以使用內存數據庫如Redis來存儲session數據,提升性能和安全性。

您如何在無狀態環境(例如API)中處理會議?您如何在無狀態環境(例如API)中處理會議?Apr 24, 2025 am 12:12 AM

在無狀態環境如API中管理會話可以通過使用JWT或cookies來實現。 1.JWT適合無狀態和可擴展性,但大數據時體積大。 2.Cookies更傳統且易實現,但需謹慎配置以確保安全性。

您如何防止與會議有關的跨站點腳本(XSS)攻擊?您如何防止與會議有關的跨站點腳本(XSS)攻擊?Apr 23, 2025 am 12:16 AM

要保護應用免受與會話相關的XSS攻擊,需採取以下措施:1.設置HttpOnly和Secure標誌保護會話cookie。 2.對所有用戶輸入進行輸出編碼。 3.實施內容安全策略(CSP)限制腳本來源。通過這些策略,可以有效防護會話相關的XSS攻擊,確保用戶數據安全。

您如何優化PHP會話性能?您如何優化PHP會話性能?Apr 23, 2025 am 12:13 AM

优化PHP会话性能的方法包括:1.延迟会话启动,2.使用数据库存储会话,3.压缩会话数据,4.管理会话生命周期,5.实现会话共享。这些策略能显著提升应用在高并发环境下的效率。

什麼是session.gc_maxlifetime配置設置?什麼是session.gc_maxlifetime配置設置?Apr 23, 2025 am 12:10 AM

theSession.gc_maxlifetimesettinginphpdeterminesthelifespanofsessiondata,setInSeconds.1)它'sconfiguredinphp.iniorviaini_set().2)abalanceisesneededeededeedeedeededto toavoidperformance andunununununexpectedLogOgouts.3)

您如何在PHP中配置會話名?您如何在PHP中配置會話名?Apr 23, 2025 am 12:08 AM

在PHP中,可以使用session_name()函數配置會話名稱。具體步驟如下:1.使用session_name()函數設置會話名稱,例如session_name("my_session")。 2.在設置會話名稱後,調用session_start()啟動會話。配置會話名稱可以避免多應用間的會話數據衝突,並增強安全性,但需注意會話名稱的唯一性、安全性、長度和設置時機。

See all articles

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱工具

MantisBT

MantisBT

Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。

SecLists

SecLists

SecLists是最終安全測試人員的伙伴。它是一個包含各種類型清單的集合,這些清單在安全評估過程中經常使用,而且都在一個地方。 SecLists透過方便地提供安全測試人員可能需要的所有列表,幫助提高安全測試的效率和生產力。清單類型包括使用者名稱、密碼、URL、模糊測試有效載荷、敏感資料模式、Web shell等等。測試人員只需將此儲存庫拉到新的測試機上,他就可以存取所需的每種類型的清單。

Atom編輯器mac版下載

Atom編輯器mac版下載

最受歡迎的的開源編輯器

EditPlus 中文破解版

EditPlus 中文破解版

體積小,語法高亮,不支援程式碼提示功能

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)