High Performance MySQL

按有用程度 按页码先后 最新笔记

• 

  第527页

  Platu_Phantom (无暇我忘)

  不同的扩展方法：Scaling MySQL Placing all of your application’s data in a single MySQL instance simply will not scale well. Sooner or later you’ll hit performance bottlenecks. The traditional solution in many types of applications is to buy more powerful servers. This is what’s known as “scaling vertically” or “scaling up.” The opposite approach is to divide your work across many c... (更多)

  不同的扩展方法：Scaling MySQL

  Placing all of your application’s data in a single MySQL instance simply will not scale well. Sooner or later you’ll hit performance bottlenecks. The traditional solution in many types of applications is to buy more powerful servers. This is what’s known as “scaling vertically” or “scaling up.” The opposite approach is to divide your work across many computers, which is usually called “scaling horizontally” or “scaling out.” We’ll discuss how to combine scale-out and scale-up solutions with consolidation, and how to scale with clustering solutions. Finally, most applications also have some data that’s rarely or never needed and that can be purged or archived. We call this approach “scaling back,” just to give it a name that matches the other strategies.

  (收起)

  2012-04-12 18:52:36   回应

  收藏

  推荐
• 

  第294页

  Platu_Phantom (无暇我忘)

  Prepared statements have a few limitations and caveats: • Prepared statements are local to a connection, so another connection cannot use the same handle. For the same reason, a client that disconnects and reconnects loses the statements. (Connection pooling or persistent connections can alleviate this problem.) • Prepared statements cannot use the query cache in MySQL versions prior ... (更多)

  Prepared statements have a few limitations and caveats: • Prepared statements are local to a connection, so another connection cannot use the same handle. For the same reason, a client that disconnects and reconnects loses the statements. (Connection pooling or persistent connections can alleviate this problem.) • Prepared statements cannot use the query cache in MySQL versions prior to 5.1. • It’s not always more efficient to use prepared statements. If you use a prepared statement only once, you might spend more time preparing it than you would just executing it as normal SQL. Preparing a statement also requires two extra roundtrips to the server (to use prepared statements properly, you should deallocate them after use). • You cannot currently use a prepared statement inside a stored function (but you can use prepared statements inside stored procedures). • You can accidentally “leak” a prepared statement by forgetting to deallocate it. This can consume a lot of resources on the server. Also, because there is a single global limit on the number of prepared statements, a mistake such as this can interfere with other connections’ use of prepared statements. • Some operations, such as BEGIN, cannot be performed in prepared statements.

  (收起)

  2012-04-12 18:50:34   回应

  收藏

  推荐
• 

  第230页

  Platu_Phantom (无暇我忘)

  MySQL doesn’t always optimize correlated subqueries badly. If you hear advice to always avoid them, don’t listen! Instead, measure and make your own decision. 所谓尽信书不如无书，自己尝试！ (更多)

  MySQL doesn’t always optimize correlated subqueries badly. If you hear advice to always avoid them, don’t listen! Instead, measure and make your own decision.

  所谓尽信书不如无书，自己尝试！ (收起)

  2012-04-12 18:48:50   回应

  收藏

  推荐

• 

  第5页

  Platu_Phantom (无暇我忘)

  MySQL, on the other hand, does offer choices. Its storage engines can implement their own locking policies and lock granularities. Lock management is a very important decision in storage engine design; fixing the granularity at a certain level can give better performance for certain uses, yet make that engine less suited for other purposes (更多)

  MySQL, on the other hand, does offer choices. Its storage engines can implement their own locking policies and lock granularities. Lock management is a very important decision in storage engine design; fixing the granularity at a certain level can give better performance for certain uses, yet make that engine less suited for other purposes

  (收起)

  2012-04-12 16:54:24   回应

  收藏

  推荐
• 

  第6页

  Platu_Phantom (无暇我忘)

  行级锁：Row locks The locking style that offers the greatest concurrency (and carries the greatest overhead) is the use of row locks. Row-level locking, as this strategy is commonly known, is available in the InnoDB and XtraDB storage engines, among others. (更多)

  行级锁：Row locks

  The locking style that offers the greatest concurrency (and carries the greatest overhead) is the use of row locks. Row-level locking, as this strategy is commonly known, is available in the InnoDB and XtraDB storage engines, among others.

  (收起)

  2012-04-12 16:54:45   回应

  收藏

  推荐
• 

  第12页

  Platu_Phantom (无暇我忘)

  MySQL也用MVCC吗？不是吧——我以为只有Oracle才支持这种东西的呢 Most of MySQL’s transactional storage engines don’t use a simple row-locking mechanism. Instead, they use row-level locking in conjunction with a technique for increasing concurrency known as multiversion concurrency control (MVCC). (更多)

  MySQL也用MVCC吗？不是吧——我以为只有Oracle才支持这种东西的呢

  Most of MySQL’s transactional storage engines don’t use a simple row-locking mechanism. Instead, they use row-level locking in conjunction with a technique for increasing concurrency known as multiversion concurrency control (MVCC).

  (收起)

  2012-04-12 16:55:58   1回应

  收藏

  推荐

• 

  第527页

  Platu_Phantom (无暇我忘)

  不同的扩展方法：Scaling MySQL Placing all of your application’s data in a single MySQL instance simply will not scale well. Sooner or later you’ll hit performance bottlenecks. The traditional solution in many types of applications is to buy more powerful servers. This is what’s known as “scaling vertically” or “scaling up.” The opposite approach is to divide your work across many c... (更多)

  不同的扩展方法：Scaling MySQL

  Placing all of your application’s data in a single MySQL instance simply will not scale well. Sooner or later you’ll hit performance bottlenecks. The traditional solution in many types of applications is to buy more powerful servers. This is what’s known as “scaling vertically” or “scaling up.” The opposite approach is to divide your work across many computers, which is usually called “scaling horizontally” or “scaling out.” We’ll discuss how to combine scale-out and scale-up solutions with consolidation, and how to scale with clustering solutions. Finally, most applications also have some data that’s rarely or never needed and that can be purged or archived. We call this approach “scaling back,” just to give it a name that matches the other strategies.

  (收起)

  2012-04-12 18:52:36   回应

  收藏

  推荐
• 

  第294页

  Platu_Phantom (无暇我忘)

  Prepared statements have a few limitations and caveats: • Prepared statements are local to a connection, so another connection cannot use the same handle. For the same reason, a client that disconnects and reconnects loses the statements. (Connection pooling or persistent connections can alleviate this problem.) • Prepared statements cannot use the query cache in MySQL versions prior ... (更多)

  Prepared statements have a few limitations and caveats: • Prepared statements are local to a connection, so another connection cannot use the same handle. For the same reason, a client that disconnects and reconnects loses the statements. (Connection pooling or persistent connections can alleviate this problem.) • Prepared statements cannot use the query cache in MySQL versions prior to 5.1. • It’s not always more efficient to use prepared statements. If you use a prepared statement only once, you might spend more time preparing it than you would just executing it as normal SQL. Preparing a statement also requires two extra roundtrips to the server (to use prepared statements properly, you should deallocate them after use). • You cannot currently use a prepared statement inside a stored function (but you can use prepared statements inside stored procedures). • You can accidentally “leak” a prepared statement by forgetting to deallocate it. This can consume a lot of resources on the server. Also, because there is a single global limit on the number of prepared statements, a mistake such as this can interfere with other connections’ use of prepared statements. • Some operations, such as BEGIN, cannot be performed in prepared statements.

  (收起)

  2012-04-12 18:50:34   回应

  收藏

  推荐
• 

  第230页

  Platu_Phantom (无暇我忘)

  MySQL doesn’t always optimize correlated subqueries badly. If you hear advice to always avoid them, don’t listen! Instead, measure and make your own decision. 所谓尽信书不如无书，自己尝试！ (更多)

  MySQL doesn’t always optimize correlated subqueries badly. If you hear advice to always avoid them, don’t listen! Instead, measure and make your own decision.

  所谓尽信书不如无书，自己尝试！ (收起)

  2012-04-12 18:48:50   回应

  收藏

  推荐