PHP网页编程之转贴一个有关MYSQL的文章.E文的.MySQLs...

exit来实现结束后面的PHP语句的执行，缩小调试范围，特别是数据库交互的程序，先输出个SQL语句看看，对了，再分析怎么会插入/删除不成功呢？这样对查错很有帮助。cache|mysql   A typical scenario
Boss: Our new website is crawling! How can it be, we have four state-of-the-art web servers - what's the problem?
You: Well, the web servers are fine - it's the database server that's struggling.
Boss: What? You told me this MySQL thing was fast, that we didn't need Oracle, and now you say it can't cope! How can this be?
You: Well, the web servers are behaving so well that they're pushing through lots of queries, and the database can't manage to process all of them at the same time. It's only one database, and lots of web servers...
Boss: It's too late to buy Oracle now - what are we going to do!?
Big Boss to Boss(in the boss's 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 we're made of money!? I'm calling in someone who knows what they're doing - you're history buddy.
Colleague (about to take your job): Wait, I think I can solve the problem!

So, what does your colleague know that you don't? 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 cache
To 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 = 1
in 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 - you'll 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 = 20M
The 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. Let's 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. Let's 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)
Let's try a smaller query:

SELECT cur_is_new FROM cur WHERE cur_user_text > 'Y'
...
2336 rows in set (0.38 sec)

Let's 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, let's 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.

Let's 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. Let's look at the status variables to see what's 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 problem here is that MySQL's query cache is case-sensitive (in fact it is byte sensitive). The query must be identical in every way - no extra spaces, no changes in case. Therefore, the above query is treated as a different query. This fact alone should be enough for you to adopt a certain convention, and ensure all application developers make use of it. I use caps for MySQL keywords, and lower case for table and field names.

Clearing the Query cache
The cache cannot stay in memory indefinitely. Luckily, MySQL is clever enough to clear it when you make any changes to the tables used in a cache query. If we insert a new record to the cur table, MySQL will clear the affected queries (and only the affected queries) from the cache:

mysql> INSERT INTO cur(cur_user_text)
    VALUES ('xxx');
Query OK, 1 row affected (0.06 sec)

mysql> SHOW STATUS LIKE '%qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_queries_in_cache | 0        |
| Qcache_inserts          | 4        |
| Qcache_hits             | 1        |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 2        |
| Qcache_free_memory      | 20962720 |
| Qcache_free_blocks      | 1        |
| Qcache_total_blocks     | 1        |
+-------------------------+----------+

Any of INSERT, UPDATE, DELETE, TRUNCATE, ALTER, DROP TABLE or DROP DATABASE potentially remove queries from the cache. You can manually clear the query cache with RESET QUERY CACHE.

Query Cache on demand
Earlier we saw there were three values for the query_cache_type. On, off and on demand. The latter option means that queries will only be cached if SQL_CACHE is specified in the query. Let's restart the server, with

query-cache-type = 2
in the configuration. Restarting the server flushes all the status variables. We run our previous query again:

SELECT cur_is_new FROM cur WHERE cur_user_text > 'Y'
...
2336 rows in set (0.27 sec)

It is back to a longer time again, as the cache has been flushed.

mysql> SHOW STATUS LIKE '%qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_queries_in_cache | 0        |
| Qcache_inserts          | 0        |
| Qcache_hits             | 0        |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 1        |
| Qcache_free_memory      | 20962720 |
| Qcache_free_blocks      | 1        |
| Qcache_total_blocks     | 1        |
+-------------------------+----------+

Nothing has been recorded. To store a query in the cache, we need to run the query with SQL_CACHE, as follows:

SELECT SQL_CACHE cur_is_new FROM cur WHERE cur_user_text > 'Y'
...
2336 rows in set (0.33 sec)

This time it has been stored in the cache.

mysql> SHOW STATUS LIKE '%qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_queries_in_cache | 1        |
| Qcache_inserts          | 1        |
| Qcache_hits             | 0        |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 1        |
| Qcache_free_memory      | 20947592 |
| Qcache_free_blocks      | 1        |
| Qcache_total_blocks     | 4        |
+-------------------------+----------+

If the cache type is set to 1, there may be times when you know the query you are running will not be repeated, or more infrequently. In these situations, you can ask MySQL not to store the results in the cache, even if they adhere to the size limitations, with the SQL_NO_CACHE clause in the SELECT statement.

Block allocation and the Query cache
MySQL allocates results into the cache in blocks, during retrieval. This allocation comes at an overhead (see the quicker time to run the above query when it was not being cached). You should not enable the query cache unless you can make good use of it. The number of free blocks (Qcache_free_blocks) can be an indication of fragmentation - a high number in relation to the total number of the blocks means that space is being wasted. In MySQL 4.1, there is another cache-related variable: query_cache_min_res_unit. This allows you to set a minimum block size. The default is 4KB. If most of your query results are small, and you see fragmentation, you should decrease this. The converse applies if most of your result sets are large. To defragment a query cache, you can use FLUSH QUERY CACHE (FLUSH TABLES has the same effect on the cache).

There are situations when a query cannot be cached, all of which make perfect sense, such as when returning the current time, a random number, user variables, or when dumping to a file. Any queries making use of the following functions, or of the following types, will not be cached:

User-Defined Functions
BENCHMARK
CONNECTION_ID
CURDATE
CURRENT_DATE
CURRENT_TIME
CURRENT_TIMESTAMP
CURTIME
DATABASE
ENCRYPT (with one parameter)
FOUND_ROWS
GET_LOCK
LAST_INSERT_ID
LOAD_FILE
MASTER_POS_WAIT
NOW
RAND
RELEASE_LOCK
SYSDATE
UNIX_TIMESTAMP (without parameters)
USER
query contains user variables
query references the mysql system database
query of the form SELECT ... IN SHARE MODE
query of the form SELECT ... INTO OUTFILE ...
query of the form SELECT ... INTO DUMPFILE ...
query of the form SELECT * FROM AUTOINCREMENT_FIELD IS NULL
queries inside transactions (in MySQL 4.0.x)
Wisely used, the query cache can make a substantial difference to struggling applications. Good luck!
  讲了这么多，无非是想说：学习PHP不仅要掌握方法，更多的是付出汗水，我不希望看到中途放弃的人，相信自己，相信自己的选择，更要相信自己的能力，如果自己想放弃，暴力一点的话，就自己抽自己一个嘴巴。

刚开始安装php的时候，我图了个省事，把php的扩展全都打开啦（就是把php.ini 那一片 extension 前面的冒号全去掉啦），这样自然有好处，以后不用再需要什么功能再来打开。

遇到出错的时候，我经常把错误信息直接复制到 google的搜索栏，一般情况都是能搜到结果的，不过有时候会搜出来一大片英文的出来，这时候就得过滤一下，吧中文的弄出来，挨着式方法。

我还是强烈建议自己搭建php环境。因为在搭建的过程中你会遇到一些问题，通过搜索或是看php手册解决问题后，你会更加深刻的理解它们的工作原理，了解到php配置文件中的一些选项设置。

当然这种网站的会员费就几十块钱。

当然这种网站的会员费就几十块钱。

环境搭建好,当你看见你的浏览器输出“it works\\\\\\\"时你一定是喜悦的。在你解决问题的时候，我强烈建议多读php手册。

php是动态网站开发的优秀语言，在学习的时候万万不能冒进。在系统的学习前，我认为不应该只是追求实现某种效果，因为即使你复制他人的代码调试成功，实现了你所期望的效果，你也不了解其中的原理。

这些中手常用的知识，当你把我说的这些关键字都可以熟练运用的时候，你可以选择自己

仓酷云

至于模板嘛，各位高人一直以来就是争论不休，我一只小菜鸟就不加入战团啦，咱们新手还是多学点东西的好。

不禁又想起那些说php是草根语言的人，为什么认得差距这么大呢。

在学习的过程中不能怕麻烦，不能有懒惰的思想。学习php首先应该搭建一个lamp环境或者是wamp环境。这是学习php开发的根本。虽然网络上有很多集成的环境，安装很方便，使用起来也很稳定、

对于初学者来说不推荐去拿钱买的。当然如果一个网站你经常去用，而且里面的资料也比较有用，最好还是买个会员比较好，毕竟那些也是别人的工作成果。

曾经犯过一个很低级的错误，我在文件命名的时候用了一个横线\\\\\\\'-\\\\\\\' 号，结果找了好几个小时的错误，事实是命名的时候 是不能用横线 \\\\\\\'-\\\\\\\' 的，应该用的是下划线  \\\\\\\'_\\\\\\\' ;

php是动态网站开发的优秀语言，在学习的时候万万不能冒进。在系统的学习前，我认为不应该只是追求实现某种效果，因为即使你复制他人的代码调试成功，实现了你所期望的效果，你也不了解其中的原理。

在我安装pear包的时候老是提示，缺少某某文件，才发现 那群extension 的排列是应该有一点的顺序，而我安装的版本的排序不是正常的排序。没办法我只好把那群冒号加了上去，只留下我需要使用的扩展。

曾经犯过一个很低级的错误，我在文件命名的时候用了一个横线\\\\\\\'-\\\\\\\' 号，结果找了好几个小时的错误，事实是命名的时候 是不能用横线 \\\\\\\'-\\\\\\\' 的，应该用的是下划线  \\\\\\\'_\\\\\\\' ;

基础有没有对学习php没有太大区别，关键是兴趣。

首先声明：我是一个菜鸟，是一个初学者。学习了一段php后总是感觉自己没有提高，无奈。经过反思我认为我学习过程中存在很多问题，我改变了学习方法后自我感觉有了明显的进步。

真正的方向了，如果将来要去开发团队，你一定要学好smarty ,phplib这样的模板引擎，