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

PHPSESSIONの障害の理由には、構成エラー、Cookieの問題、セッションの有効期限が含まれます。 1。構成エラー:正しいセッションをチェックして設定します。save_path。 2.Cookieの問題:Cookieが正しく設定されていることを確認してください。 3.セッションの有効期限:セッションを調整してください。GC_MAXLIFETIME値はセッション時間を延長します。

PHPでセッションの問題をデバッグする方法は次のとおりです。1。セッションが正しく開始されるかどうかを確認します。 2.セッションIDの配信を確認します。 3.セッションデータのストレージと読み取りを確認します。 4.サーバーの構成を確認します。セッションIDとデータを出力し、セッションファイルのコンテンツを表示するなど、セッション関連の問題を効果的に診断して解決できます。

session_start()への複数の呼び出しにより、警告メッセージと可能なデータ上書きが行われます。 1)PHPは警告を発し、セッションが開始されたことを促します。 2)セッションデータの予期しない上書きを引き起こす可能性があります。 3)session_status()を使用してセッションステータスを確認して、繰り返しの呼び出しを避けます。

PHPでのセッションライフサイクルの構成は、session.gc_maxlifetimeとsession.cookie_lifetimeを設定することで達成できます。 1)session.gc_maxlifetimeサーバー側のセッションデータのサバイバル時間を制御します。 0に設定すると、ブラウザが閉じているとCookieが期限切れになります。

データベースストレージセッションを使用することの主な利点には、持続性、スケーラビリティ、セキュリティが含まれます。 1。永続性:サーバーが再起動しても、セッションデータは変更されないままになります。 2。スケーラビリティ:分散システムに適用され、セッションデータが複数のサーバー間で同期されるようにします。 3。セキュリティ:データベースは、機密情報を保護するための暗号化されたストレージを提供します。

PHPでのカスタムセッション処理の実装は、SessionHandlerInterfaceインターフェイスを実装することで実行できます。具体的な手順には、次のものが含まれます。1)CussentsessionHandlerなどのSessionHandlerInterfaceを実装するクラスの作成。 2)セッションデータのライフサイクルとストレージ方法を定義するためのインターフェイス(オープン、クローズ、読み取り、書き込み、破壊、GCなど)の書き換え方法。 3)PHPスクリプトでカスタムセッションプロセッサを登録し、セッションを開始します。これにより、データをMySQLやRedisなどのメディアに保存して、パフォーマンス、セキュリティ、スケーラビリティを改善できます。

SessionIDは、ユーザーセッションのステータスを追跡するためにWebアプリケーションで使用されるメカニズムです。 1.ユーザーとサーバー間の複数のインタラクション中にユーザーのID情報を維持するために使用されるランダムに生成された文字列です。 2。サーバーは、ユーザーの複数のリクエストでこれらの要求を識別および関連付けるのに役立つCookieまたはURLパラメーターを介してクライアントに生成および送信します。 3.生成は通常、ランダムアルゴリズムを使用して、一意性と予測不可能性を確保します。 4.実際の開発では、Redisなどのメモリ内データベースを使用してセッションデータを保存してパフォーマンスとセキュリティを改善できます。

APIなどのステートレス環境でのセッションの管理は、JWTまたはCookieを使用して達成できます。 1。JWTは、無国籍とスケーラビリティに適していますが、ビッグデータに関してはサイズが大きいです。 2.cookiesはより伝統的で実装が簡単ですが、セキュリティを確保するために慎重に構成する必要があります。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

SecLists
SecLists は、セキュリティ テスターの究極の相棒です。これは、セキュリティ評価中に頻繁に使用されるさまざまな種類のリストを 1 か所にまとめたものです。 SecLists は、セキュリティ テスターが必要とする可能性のあるすべてのリストを便利に提供することで、セキュリティ テストをより効率的かつ生産的にするのに役立ちます。リストの種類には、ユーザー名、パスワード、URL、ファジング ペイロード、機密データ パターン、Web シェルなどが含まれます。テスターはこのリポジトリを新しいテスト マシンにプルするだけで、必要なあらゆる種類のリストにアクセスできるようになります。

SublimeText3 Linux 新バージョン
SublimeText3 Linux 最新バージョン

DVWA
Damn Vulnerable Web App (DVWA) は、非常に脆弱な PHP/MySQL Web アプリケーションです。その主な目的は、セキュリティ専門家が法的環境でスキルとツールをテストするのに役立ち、Web 開発者が Web アプリケーションを保護するプロセスをより深く理解できるようにし、教師/生徒が教室環境で Web アプリケーションを教え/学習できるようにすることです。安全。 DVWA の目標は、シンプルでわかりやすいインターフェイスを通じて、さまざまな難易度で最も一般的な Web 脆弱性のいくつかを実践することです。このソフトウェアは、

ZendStudio 13.5.1 Mac
強力な PHP 統合開発環境

Safe Exam Browser
Safe Exam Browser は、オンライン試験を安全に受験するための安全なブラウザ環境です。このソフトウェアは、あらゆるコンピュータを安全なワークステーションに変えます。あらゆるユーティリティへのアクセスを制御し、学生が無許可のリソースを使用するのを防ぎます。

ホットトピック









