工作两年多的小白是一个很努力的员工，每天除了用心工作外，还坚持充电学习，两年来他除了把ORACLE10G和ORACLE11G的官方文档几乎读了个遍外，还购买了不少相关的书籍来学习。由于小白的项目组工作强度大，时常需要加班，因此小白工作学习外的时间就只够留给吃饭和睡觉了。那他的工作表现很出色吗，天道是否一定酬勤？实际情况却是很不如人意，虽然他了解很多相关知识，可是在实际工作应用中却不得要领，频频出错，领导经常对其提出批评，他自己也相当烦恼。
其实小白只是因为缺少了一种称之为“意识”的东西，这个意识就是，该如何学习。在他的学习过程中，他犯了很多错误。
1. 忽略了知识的重点。
小白读完了ORACLE官方文档的几乎所有内容，毅力让人钦佩！遗憾的是，他忽略了二八现象这个事实：20%的知识，解决80%的问题。小白根本不需要读完ORACLE所有文档，他所在的项目组是从事数据库开发相关工作的，而他却花费了大量的时间阅读完了至今他都尚未开始从事的数据库管理相关知识，比如备份恢复、RAC、DATAGUARD部署及高级数据同步复制相关的技术。这完全是没有必要的。
另外语法方面的资料，小白根本也无需去细读，去记忆，因为平时用的多的语法，自然记得住，遇到偶尔忘记的场合再去官方文档翻阅即可，现在GOOGLE等搜索引擎也非常强大，搜索到相关语法易如反掌。
人的精力是有限的，如果我们做到当前做什么事对应学习什么知识，尽量理解原理而不强记语法，将能省下多少宝贵的时间啊。
2. 从未考虑知识落地
小白曾经对我说过自己的烦恼，向我说明了他有多努力，看过了多少资料。我试探性的问他是否知道ORACLE的体系架构是什么？他很自信的做了回答，滔滔不绝，甚至还画了草图给我，回答的相当让人满意。我又问他是否知道索引的结构和原理是什么？再次得到完美的答复。
接下来我再问他，知道这个体系架构对我们工作有啥帮助呢？他一下子回答不上来了。我继续问他，那索引的结构和原理对我们工作中的数据库应用有啥好处呢？再次答不上来。
原来这就是问题的关键所在！
知识要落地，要思考应用的场合，这就是我除了要让他把握学习重点外的第二个建议。他的学习其实就是为了学习而学习，没有思考应用场景的学习，是没有任何意义。
后来我建议小白来听我在公司开讲的ORACLE系列讲座，让他明白原来了解体系结构后我们居然可以将一条SQL从42秒调整到不足0.01秒；了解索引结构后，我们居然可以优化我们身边最为常见的SQL语句，比如COUNT(*)，MAX()等等。而在此之前，这些语句根本不会让他对索引产生联想。他终于彻底明白了什么叫知识落地，明白了意识有多么重要！
我最后强调，不只是ORACLE，其实学习任何技术都一样的，没有思考过你所学的某技术有什么用，没有想过如何落地，如何应用到实际工作中去，都是毫无意义的学习，纯粹浪费生命。
3. 选择技术使用场景
近来小白连续犯错，他学习了并行度这个章节后，知道并行可以有效的利用多个CPU，将自己的代码加进了并行度，结果忽略了生产系统不只是跑他这一个应用这个事实。导致代码上生产后生产系统资源大量争用。直至最后我们定位到问题在他的代码中，将写法修正，取消了并行度后，系统终于恢复正常。
他为什么会犯这个错误，主要是因为他只专注于技术本身而忽略了应用的场景，如果是凌晨2点的某个大任务操作，他的这个设置就很好，因为那个时刻大多其他应用都已经停止运行了，资源不利用白不利用。
这就是什么时候选择什么技术。小白还有一个有趣的故事，就是在我给他提这第三个建议之后的一周，他又使用了并行，这次他不是在代码中写死，而是选择临时性场合使用，在凌晨2点运行系列特定脚本。结果这次他运行的比想象的慢的多，还不如之前未用并行的时候。
大家知道什么原因吗，其实还是因为不知道什么时候选择什么技术。这次他不会影响他人了，因为凌晨静悄悄。但是他影响了自己。因为他的任务的特点是小而多，平均0.01秒不到可以完成一条SQL执行。他忽略了另外一个细节，并行是需要调度的，调度是需要开销的，调度的开销甚至达到0.1秒，那不是越跑越慢了。所以小任务实际上是不需要考虑并行的。
小白的故事说完了，其实要是早些年，他或许不会有这些苦恼，因为学习资料少，他即便不抓重点也不至于学到筋疲力尽；此外他的诸多失误都和性能有关，而早些年大多IT系统压力很小，在基本功能满足后性能问题几乎可以忽略不计，那小白也就没错可犯了。
再次强调，当今的IT建设项目，如果不对海量数据和高并发带来的性能问题进行有效的架构设计、部署规划，你的项目基本上就被判了死刑。而ORACLE新版本为什么对应大量技术文档，很大一部分原因是ORACLE新版本提供了更多的性能调优产品。为什么现在新技术如此繁多，其实也是源于此，难道内存数据库和列式数据及分布式数据库的产生，不是为了让系统跑的更快一些吗，只是这里要注意，他们不可能替代传统关系型数据库，因为他们都有各自适合的应用场合。
其实小白只是因为缺少了一种称之为“意识”的东西，这个意识就是，该如何学习。在他的学习过程中，他犯了很多错误。
1. 忽略了知识的重点。
小白读完了ORACLE官方文档的几乎所有内容，毅力让人钦佩！遗憾的是，他忽略了二八现象这个事实：20%的知识，解决80%的问题。小白根本不需要读完ORACLE所有文档，他所在的项目组是从事数据库开发相关工作的，而他却花费了大量的时间阅读完了至今他都尚未开始从事的数据库管理相关知识，比如备份恢复、RAC、DATAGUARD部署及高级数据同步复制相关的技术。这完全是没有必要的。
另外语法方面的资料，小白根本也无需去细读，去记忆，因为平时用的多的语法，自然记得住，遇到偶尔忘记的场合再去官方文档翻阅即可，现在GOOGLE等搜索引擎也非常强大，搜索到相关语法易如反掌。
人的精力是有限的，如果我们做到当前做什么事对应学习什么知识，尽量理解原理而不强记语法，将能省下多少宝贵的时间啊。
2. 从未考虑知识落地
小白曾经对我说过自己的烦恼，向我说明了他有多努力，看过了多少资料。我试探性的问他是否知道ORACLE的体系架构是什么？他很自信的做了回答，滔滔不绝，甚至还画了草图给我，回答的相当让人满意。我又问他是否知道索引的结构和原理是什么？再次得到完美的答复。
接下来我再问他，知道这个体系架构对我们工作有啥帮助呢？他一下子回答不上来了。我继续问他，那索引的结构和原理对我们工作中的数据库应用有啥好处呢？再次答不上来。
原来这就是问题的关键所在！
知识要落地，要思考应用的场合，这就是我除了要让他把握学习重点外的第二个建议。他的学习其实就是为了学习而学习，没有思考应用场景的学习，是没有任何意义。
后来我建议小白来听我在公司开讲的ORACLE系列讲座，让他明白原来了解体系结构后我们居然可以将一条SQL从42秒调整到不足0.01秒；了解索引结构后，我们居然可以优化我们身边最为常见的SQL语句，比如COUNT(*)，MAX()等等。而在此之前，这些语句根本不会让他对索引产生联想。他终于彻底明白了什么叫知识落地，明白了意识有多么重要！
我最后强调，不只是ORACLE，其实学习任何技术都一样的，没有思考过你所学的某技术有什么用，没有想过如何落地，如何应用到实际工作中去，都是毫无意义的学习，纯粹浪费生命。
3. 选择技术使用场景
近来小白连续犯错，他学习了并行度这个章节后，知道并行可以有效的利用多个CPU，将自己的代码加进了并行度，结果忽略了生产系统不只是跑他这一个应用这个事实。导致代码上生产后生产系统资源大量争用。直至最后我们定位到问题在他的代码中，将写法修正，取消了并行度后，系统终于恢复正常。
他为什么会犯这个错误，主要是因为他只专注于技术本身而忽略了应用的场景，如果是凌晨2点的某个大任务操作，他的这个设置就很好，因为那个时刻大多其他应用都已经停止运行了，资源不利用白不利用。
这就是什么时候选择什么技术。小白还有一个有趣的故事，就是在我给他提这第三个建议之后的一周，他又使用了并行，这次他不是在代码中写死，而是选择临时性场合使用，在凌晨2点运行系列特定脚本。结果这次他运行的比想象的慢的多，还不如之前未用并行的时候。
大家知道什么原因吗，其实还是因为不知道什么时候选择什么技术。这次他不会影响他人了，因为凌晨静悄悄。但是他影响了自己。因为他的任务的特点是小而多，平均0.01秒不到可以完成一条SQL执行。他忽略了另外一个细节，并行是需要调度的，调度是需要开销的，调度的开销甚至达到0.1秒，那不是越跑越慢了。所以小任务实际上是不需要考虑并行的。
小白的故事说完了，其实要是早些年，他或许不会有这些苦恼，因为学习资料少，他即便不抓重点也不至于学到筋疲力尽；此外他的诸多失误都和性能有关，而早些年大多IT系统压力很小，在基本功能满足后性能问题几乎可以忽略不计，那小白也就没错可犯了。
再次强调，当今的IT建设项目，如果不对海量数据和高并发带来的性能问题进行有效的架构设计、部署规划，你的项目基本上就被判了死刑。而ORACLE新版本为什么对应大量技术文档，很大一部分原因是ORACLE新版本提供了更多的性能调优产品。为什么现在新技术如此繁多，其实也是源于此，难道内存数据库和列式数据及分布式数据库的产生，不是为了让系统跑的更快一些吗，只是这里要注意，他们不可能替代传统关系型数据库，因为他们都有各自适合的应用场合。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26243632/viewspace-755407/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/26243632/viewspace-755407/
扫一扫
1009
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
