mysql_connect v/s mysql_pconnect

mysql_connect

This function will create a new connection to the database once your script start executing and closes the connection to the database once script execution ends. This will make a connection to database every time our script start the execution.

mysql_pconnect

When you tries to connect your database using this function, then it will search for existing connection made to the database using same username and password, if the connection found then it will return the resource ID, otherwise it will make the connection and return the resource ID.

After one time of connection it will just return the resource ID (if found) and it will not try to make the connection every time the script calls, it will also not close the connection once the script ends. This is called persistent connection.

But mysql_pconnect does require some tuning of the servers and you may need to limit the numbers of connections / children and configure timeouts and how to deal with idle children.

When to use which function?

You should use mysql_pconnect() if your site have high traffic.

If PHP and MySQL are on the same server or local network, the connection time may be negligible, in which case there is no advantage to persistent connections.

Things to keep in mind while using mysql_pconnect

When you lock a table, normally it is unlocked when the connection closes, but since persistent connections do not close, any tables you accidentally leave locked will remain locked, and the only way to unlock them is to wait for the connection to timeout or kill the process. The same locking problem occurs with transactions.

Normally temporary tables are dropped when the connection closes, but since persistent connections do not close, temporary tables aren’t so temporary. If you do not explicitly drop temporary tables when you are done, that table will already exist for a new client reusing the same connection. The same problem occurs with setting session variables.

Apache does not work well with persistent connections. When it receives a request from a new client, instead of using one of the available children which already has a persistent connection open, it tends to spawn a new child, which must then open a new database connection. This causes excess processes which are just sleeping, wasting resources, and causing errors when you reach your maximum connections, plus it defeats any benefit of persistent connections.

source: http://www.xpertdeveloper.com/2013/06/mysql_connect-vs-mysql_pconnect/

MySql: Có nên sử Index? Khi nào thì nên sử dụng Index?

Với tiêu đề trên bạn nào không làm việc với MySQL nhiều sẽ thấy nực cười. Tất nhiên là nên sử dụng index rồi, test với một số dòng nhất định thì thấy lý thuyết mình học được trên trường đúng quá. Ngay cả mình cũng vậy bao nhiêu năm lúc nào cũng đinh ninh là cứ oánh index là khi select kiểu gì cũng nhanh hơn. Nhưng gần đây website của mình sinh ra một table tới 60 triệu dòng, khá là lớn, thấy hệ thống châm quá nên cặm cụi debug xem thế nào, bắt đầu từ MySQL, explain xem mấy câu query chạy chậm quá, thế là lên hỏi pác google rồi thấy sự thực đau lòng, select chậm một phần là do mình oánh index híc. Nếu bạn cứ thử test với table nào của mình có nhiều dòng một chút sẽ thấy ngay. Lý do là ở đâu, nếu bạn oánh index 1 column, nhưng số giá trị unique trong column đó quá thấp thì bạn không nên dùng index đối với trường hợp này. bạn có thể tính điều này qua công thức

Độ hiệu quả = tổng số dòng trong tables) / (tổng số dòng unique trong column) 

=1 Quá tốt, sự khác nhau của mỗi dòng là rất nhiều bà BTree hoạt động rất tốt, bạn nên dùng index

+———-+

| count(*) |
+----------+
| 817666 |
+----------+
1 row in set (0.63 sec)

+--------------------------+
| count(distinct username) |
+--------------------------+
| 817666 |
+--------------------------+
1 row in set (1.63 sec)

 

Nhưng nếu trong trường hợp tổng giá trị distinct của bạn quá ít so với số dòng của table giống vd dưới thì bạn không nên dùng index trong trường hợp này

+---------------------+
| count(distinct age) |
+---------------------+
| 83 |
+---------------------+
1 row in set (0.63 sec)

Chỉ có 83 sự khác biệt trong column trên => theo công thức trên Độ hiệu quả = 0.000101508 => gần như bằng 0 => nếu dùng index sẽ chậm hơn là quét toàn table rất nhiều => không nên dùng index trong trường hợp này