Kalıcı bağlantılar MySQL için gereksiz olmalıdır. Bir bağlantısı pahalı ve zaman alıcı, bu nedenle yeniden bir bağlantı kullanabilirsiniz eğer büyük bir kazan yapma (Oracle gibi) diğer veritabanları içinde. Ama daha iyi bir şekilde sorunu çözer veritabanı teklif bağlantı havuzu, bu markalar.

MySQL veritabanı bağlantısı yapma bu diğer markalara kıyasla hızlı, böylece kalıcı bağlantılarını kullanarak oransal veritabanından başka bir marka için olandan MySQL için daha az fayda verir.

Kalıcı bağlantılar da bir dezavantajı var. Veritabanı sunucusu bağlantıları gerekli olsun veya olmasın, her bağlantı için kaynak ayırmaktadır. Bağlantıları boşta iseniz Yani hiçbir amaç için kaynakların israf bir sürü bakın. 10.000 boşta bağlantıları ulaşmak olacak eğer ben bilmiyorum, ama yüz hatta birkaç maliyetlidir.

Bağlantıları devlet var, ve daha önce başka bir PHP isteği tarafından kullanılan bir oturumu bilgilerini "miras" için bir PHP istek için uygunsuz olacaktır. Kalıcı bağlantı kullanmak Örneğin, geçici tablolar ve kullanıcı değişkenleri normalde bir bağlantı kapatır gibi temizledik, ama değil. Karakter seti ve harmanlama gibi aynı şekilde oturum tabanlı ayarlar. Ayrıca, LAST_INSERT_ID() oturumu sırasında son oluşturulan id rapor verecek - bir önceki PHP isteği sırasında oldu bile.

MySQL için, en azından, muhtemelen kendi yararları ağır basar kalıcı bağlantıların olumsuz. Ve yüksek ölçeklenebilirlik elde etmek için diğer, daha iyi teknikler vardır.

Mart 2014 güncelleyin:

MySQL bağlantı hızı hep düşük RDBMS'in diğer markalara kıyasla, ama o daha iyi oluyor.

Bkz http://mysqlserverteam.com/improving-connectdisconnect-performance/

MySQL 5.6 biz kod taşıma bağlanır ve keser optimize üzerinde çalışmaya başladı. Ve bu iş MySQL 5.7 hızlandı. Bu blog yazısı ilk biz elde ettik sonuçlarını göstermek ve daha sonra biz onları almak için yaptıklarını anlatacağız.

Daha fazla ayrıntı ve hız karşılaştırmaları için blogunu okuyun.

Temelde bağlantıları tutan karşı bağlantı oluşturma maliyeti dengelemek zorunda. Konu kurulum zamanında ve TCP / IP kurulum zamanlı web sunucusundan - MySQL yeni bir bağlantı kurma çok hızlı olsa da, hala maliyeti. Bu yüksek yeterince trafik sitede belirgindir. Ne yazık ki, PHP bağlantılarının kalıcılığı üzerinde herhangi bir kontrole sahip değildir. Yani cevap MySQL boşta kalma zaman aşımı uzun bir yol (gibi aşağı 20 saniye) düşürmek için, ve iplik önbellek boyutu kadar. Birlikte, bu genellikle oldukça iyi çalışıyor.

Kapak tarafında, uygulama bağlantı durumunu saygı gerekiyor. Eğer DEĞİL BULUNMASI HALİNDE CREATE ve (örneğin adınız gibi dahil olarak) benzersiz onları adlandırma yok gibi TABLO, bir çok yardımcı olur truncate sonra kullanarak, geçici tabloları kullanıyorsanız oturumu inç olduğunu ne devlet hakkında hiçbir varsayımlar yapar eğer en iyisidir. İşlemler biraz daha sorunlu; ama kodu her zaman sadece durumda, üst ROLLBACK yapabilirsiniz.

Bu 10000 bağlantıları ulaşmak edeceğiz çok düşüktür. Her neyse, official source gidin. (Vurgu benim).

If persistent connections don't have any added functionality, what are they good for?

The answer here is extremely simple -- efficiency. Persistent connections are good if the overhead to create a link to your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every time it processes a page that requires connecting to the SQL server. This means that for every child that opened a persistent connection will have its own open persistent connection to the server. For example, if you had 20 different child processes that ran a script that made a persistent connection to your SQL server, you'd have 20 different connections to the SQL server, one from each child.

Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped. Check your database documentation for information on handling abandoned or idle connections.

mysql_connect() ve mysql_pconnect() hem veritabanı bağlantısı için çalışan ama az farkla edilir. mysql_pconnect() olarak, p persistance bir bağlantı anlamına gelir.

Biz mysql_connect() işlevini kullanırken, her zaman bu isteğine bağlı olarak, veritabanı bağlantısını açıp kapatıyor.

Ama mysql_pconnect() işlevi durumunda:

• Bağlarken ilk, fonksiyon zaten aynı host, kullanıcı adı ve şifre ile açık olan bir (kalıcı) bir bağlantı bulmaya çalışacaktı. Bulursa, bunun için bir tanımlayıcı yerine yeni bir bağlantı açma iade edilecektir.

• Script çalışması bittiğinde İkincisi, SQL sunucusuna bağlantı kapalı olmayacak. Bunun yerine, bağlantı (mysql_close() değil tarafından kurulan yakın ilişki mysql_pconnect()), ileride kullanılmak üzere açık kalacaktır.

Sitenizde traffice bir çok şey var mysql_pconncet() yararlıdır. Her istek için o zaman bir bağlantıyı açmak değil ama o havuz alacaktır. Bu sitenizin verimliliğini artıracaktır. Ama genel kullanım için mysql_connect () en iyisidir.

Mysql_pconnect() İlk bağlantı varlığını kontrol eder.

Detay bulmuş olabilir here.