作者: Baron Schwartz / Peter Zaitsev / Vadim Tkachenko
出版社: O'Reilly Media
出版年: 2012-3-23
页数: 826
定价: USD 49.99
装帧: Paperback
ISBN: 9781449314286
作者简介 · · · · · ·
Peter Zaitsev,MySQL AB公司高性能组的前任经理,现正运作着mysqlperformanceblog.com 网站。他擅长于帮助管理员为每天有着数以百万计访问量的网站修补漏洞,使用数百台服务器来处理TB级的数据。他常常为了找到一个解决方案而修改和升级软硬件(比如查询优化)。Peter还经常在讨论会上发表演讲。
Vadim Tkachenko,Perc... (展开全部) Baron Schwartz 是一名软件工程师,他住在弗吉尼亚州的Charlottesville,在网上用的名字是Xaprb,这是他名字的第一部分按QWERTY键盘的顺序打在Dvorak键盘上时显示出来的名字。当他不忙于解决有趣的编程挑战时,Baron就会和他的妻子Lynn、狗Carbon一起享受闲暇时光。他的关于软件工程的博客地址是http://www.xaprb.com
Peter Zaitsev,MySQL AB公司高性能组的前任经理,现正运作着mysqlperformanceblog.com 网站。他擅长于帮助管理员为每天有着数以百万计访问量的网站修补漏洞,使用数百台服务器来处理TB级的数据。他常常为了找到一个解决方案而修改和升级软硬件(比如查询优化)。Peter还经常在讨论会上发表演讲。
Vadim Tkachenko,Percona公司的合伙人,该公司是一家专业的MySQL性能咨询公司。他过去是MySQL AB公司的性能工程师。作为一名在多线程编程和同步领域里的专家,他的主要工作是基准测试、特征分析和找出系统瓶颈。他还在性能监控和调优方面做着一些工作,使MySQL在多个CPU上更具有伸缩性。
Jeremy D. Zawodny和他的两只猫在1999年底从俄亥俄州的西北部搬到了硅谷,这样他就能为Yahoo!工作了——那时他刚好亲眼见证了.com泡沫的破灭。他在Yahoo!工作了八年半,将MySQL和其他开源技术组合起来使用,找到有趣的、令人兴奋的用途,而它们往往也是很大的用途。
近段时间,他重新发掘出了对飞行的热爱。其实,早在2003年年初,他就已经取得了私人滑翔机飞行员的执照,2005年获得商业飞行员的定级。从那时起,他花了大量的空闲时间驾驶滑翔机,飞翔在Hollister、加利福尼亚和Tahoe湖地区上空。他偶尔还会驾驶单引擎轻型飞机,和别人共同拥有一架Citabria 7KCAB和一架Cessna 182。临时的咨询工作可以帮助他支付飞行账单。
Jeremy和他可人的妻子及四只猫生活在加州的旧金山湾区。他的博客地址是jeremy.zawodny.com/blog。
Arjen Lentz 出生在阿姆斯特丹,但从千禧年以来他和他美丽的女儿Phoebe、黑猫 Figaro一直生活在澳大利亚的Queensland。Arjen最初是C程序员,在MySQL AB公司(2001-2007)里是第25号职员。在2007年短暂的休息之后,Arjen创建了Open Query(http://openquery.com
Derek J. Balling自1996年以来就一直是Linux系统管理员。他协助Yahoo!那样的公司和Vassar学院那样的机构建立和维护服务器基础设施,也曾为Perl杂志和其他一些在线杂志撰写文章,并一直为LISA(Large Installation System Administration)会议的编程委员会服务。目前,他作为数据中心经理受雇于Answers.com。
当不做与计算机有关的事情时,Derek喜欢和他的妻子Debbie及他们的动物群(四只猫和一只狗)在一起。在博客http://blog.megacity
按有用程度 按页码先后 最新笔记
-
第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 回应
书评 · · · · · · (共9条) 我来评论这本书
热门评论 最新评论
mysql卫道者
-
- Once(借你双脚,赠我双目) 当然,如果你英文不错,该书的原版以及几本著名的外文mysql书会是更好的选择。毕竟无论翻译者水平多高,信息经过一层传递总是会混进不少的噪声的,更何况是如此专业的一本长篇巨著。如果你像我那样不满足爬行于E文的那低阅读效率,那么揣着这么一本我感觉翻译质量还凑合的字典在手边还是一个不错的选择。是的,我是把它当字典一般扫完的,...... (4回应)2010-05-28 38/39有用来自 电子工业出版社2010版
如中国足球一样糙的翻译
-
- 量子纠缠 在MySQL社区,这是一本重量级的书,我不知道出版社是怎么挑选译者的,但是很明显,我个人的意见,这次挑选非常的失败。书中98页倒数第4行的"binary search"的翻译(二进制搜索)已经道出了一切,但凡学过计算机的,我估计都不能做出这样的翻译。在计算机领域,二进制是一个专门的术语,有特定的含义。我不仅怀疑译者根本...... (7回应)2010-07-03 26/26有用来自 电子工业出版社2010版
翻译的极差
-
- 王永良 翻译这本书需要很强的专业知识,mysql不用说了,算法,计算机组成原理等。我敢说这几位翻译的作者计算机知识不好,英语基础也烂,翻译的真恶心,糟蹋这么经典这么权威的书了。强烈建议看原版!...... (10回应)2010-07-16 4/4有用来自 电子工业出版社2010版
书是好书,但是翻译太烂了
-
- yanyan2012 书是好书,但是翻译太烂了 建议大家还是看英文原版吧 书想覆盖的东西太多了,从存储引擎到硬件到优化 所以我觉得都是点到为止而已,不是太深入 因此我反而觉得适合一些初级用户而非高级用户 不关怎么说英文原版书还是值得推荐的......2010-12-23 1/1有用来自 电子工业出版社2010版
刚开始看
-
- tany 当然,刚开始看还写不出什么深入的理解和心得体会。 只是刚拿到手中看了那么几十页,感觉书中的内容排版很紧凑,可见作者没有把此书印刷得超级厚,然后来要价的嫌疑。 看了很多网友的评论,对Mysql有如此高的评论的书在国内还着实不多。 至于翻译水平的问题,我还不敢来评论,只是以本人的水准,看英文原版那还不如看翻译之后......2010-11-11 1/1有用来自 电子工业出版社2010版
High Performance MySQL Second Edition
-
- 涅瓦纳(一个沉默的观影者与读书人) "High Performance MySQL" is the definitive guide to building fast, reliable systems with MySQL. Written by noted experts with years of real-world experience bui......2011-07-30 来自 O'Reilly Media2008版
High Performance MySQL
-
- 涅瓦纳(一个沉默的观影者与读书人) 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了......2012-04-23
求转让,英文版的
-
- 游来游去 这本好书,早就想看了,有没有闲置的,转让一下。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。......2011-05-12 来自 O'Reilly Media2004版
MySQL的权威书籍,以及其他一些通用理念
-
- 竹十一(竹十一) 这本书基本上涵盖了MySQL 的各个方面,以InnoDB 为主。MyISAM 也有不少涉及。其他的引擎 基本没什么东西。 这本书对我来讲比较有意义的是MySQL 之外的部分。很多数据库设计、维护方面通用的理念 。 这比《ORACLE 9i/10g》 好得多,它只是讲了ORACLE的东西。 ......2011-04-26 来自 电子工业出版社2010版
第一个在"High Performance MySQL"的论坛里发言
- > 点这儿转让 有23人想读,手里有一本闲着?
这本书的其他版本 · · · · · · ( 全部5 )
- 开明出版社版 2009-4 / 15人读过 / 有售
- 电子工业出版社版 2010年1月 / 124人读过
- O'Reilly Media版 2004-4-15 / 87人读过
- O'Reilly Media版 2008-6-25 / 74人读过
以下豆列推荐 · · · · · ·
- [Computer] programming (妖貓)
- MySQL (init.d)
谁读这本书?
订阅关于High Performance MySQL的评论:
feed: rss 2.0

