目前最常用的动态网页语言有Perl、PHP、JSP、ASP和ASP.NET，下面对这五种语言进行一些技术性的比较。
1、Perl
Perl是一种很古老的脚本语言。最初的Web应用大多是用Perl编写的，Perl很像C语言，使用非常灵活，对于文件操作和处理具有和C语言一样的方便快捷。
也正是因为Perl的灵活性和“过度”的冗余语法，也因此导致许多Perl程序的代码令人难以阅读和维护，因此使用的人在逐渐减少，并且目前有被python替代的可能。另外，Perl对于CPU的消耗似乎较高，效率有一些不足。
C#是一种令人耳目一新的面向对象编程语言，它具有功能强大和语言简洁高效、与Web技术紧密结合、完整的安全和错误处理机制等特点。C#的特点主要体现在以下几个方面。
1、简单方便性
C#比起C+ +的一个明显特点就是简单。C#去掉了很多C+ +中经常使用的操作符，例如：“：：”和“－>”等，虽然它们在C+ +运用中有着比较重要的用处，但是对于程序设计新手，操作符毕竟还是一道难关。在C#中仅使用“.”操作符就完成对方法、属性调用设置。
不论是Scale Up还是Scale Out，不管如何设计架构，保证数据的最终一致性都是绝对不能违背的原则，保证这个原则的重要性大家肯定非常清楚。
数据一致性的保证就像事务完整性一样，在我们对系统进行Scale Out设计的时候，也可能会遇到一些问题。当然，如果是Scale Up，可能就很少遇到这类麻烦了。当然，在很多人眼中，数据的一致性在某种程度上也是属于事务完整性的范畴。不过这里为了突出其重要性和相关特性，将它单独提出来分析。
如何在Scale Out的同时较好地保证数据一致性呢？这个问题和保证事务完整性一样让我们头痛，它同样受到了很多架构师的关注。经过很多人的实践，大家最后总结出了BASE模型。即：基本可用，柔性状态，基本一致和最终一致。这几个词看似复杂深奥，其实大家可用简单地理解为非实时的一致性原则。
Query语句优化的基本思路的了解有助于我们更加深入的了解MySQL Query。Query语句优化的基本思路主要体现在以下几个方面。
1、优化更需要优化的Query
为什么需要优化更需要优化的Query？我想这个问题不需要过多的解释。那什么样的Query更需要优化呢？这个问题需要从对整个系统的影响来考虑。哪个Query的优化能给系统整体带来更大的收益，就更需要优化。一般来说，高并发低消耗的Query对整个系统的影响远比低并发高消耗的大。下面可以通过以下一个非常简单的案例分析充分说明问题。
Full-text索引也就是全文索引，目前在MySQL中仅有MyISAM存储引擎支持它，但并不是所有的数据类型都支持。目前，仅有CHAR、VARCHAR和TEXT这三种数据类型的列可以建Full-text索引。
一般来说，fulltext索引主要用来替代效率低下的LIKE‘%***%’操作。实际上，Full-text索引并不是只能简单地替代传统的全模糊LIKE操作，它能通过多字段组合的Full-text索引一次全模糊匹配多个字段。
Full-text索引和普通的B-Tree索引实现区别较大，虽然它同样是以B-Tree形式来存放索引数据的，但是它并不是通过字段内容的完整匹配，而是通过特定的算法，将字段数据进行分割后再进行的索引。一般来说MySQL系统会按照最小4个字节来分隔。在整个Full-text索引中，存储内容被分为两部分，一部分是分隔前的索引字符串数据集合，另一部分是分隔后的词（或者词组）索引信息。所以，Full-text索引中，真正的B-Tree索引结构的叶节点中的并不是表中的原始数据，而是分词之后的索引数据。在B-Tree索引结构的节点信息中，存放了各个分隔后的词信息，以及指向包含该词的分隔前字符串信息在索引数据集合中的位置信息。
实际上，并没有一个非常明确的定律可以清晰地定义什么字段应该创建索引，什么字段不该创建索引。因为应用场景实在是太复杂，存在太多的差异。当然，还是仍然能够找到几点基本的判定策略来帮助分析的。
1、较频繁的作为查询条件的字段应该创建索引
提高数据查询检索的效率最有效的办法就是减少需要访问的数据量，我们知道索引正是减少通过索引键字段作为查询条件的Query的IO量之最有效手段。所以一般来说应该为较为频繁的查询条件字段创建索引。
大字段垂直拆分策略相对于适度冗余策略在做法上可以说是完全相反的。适度冗余策略是将别的表中的字段拿过来在自己身上也存一份，而大字段垂直拆分简单来说就是将自己身上的字段拆分出去放在另外的表里。什么样的字段适合从表中拆分出去呢？
首先，肯定得是大字段。为什么？原因很简单，就是因为它大。大字段一般都是存放着一些较长的detail信息，如文章的内容、帖子的内容、产品的介绍等。
其次是和表中其他字段相比访问频率明显要少很多的。由于大字段存放的内容较多，大部分情况都占整条记录的80%以上，而数据库中数据在数据文件中的格式一般都是以单条记录为单位来存放的。也就是说，如果要查询某些记录的某几个字段，数据库并不是只需访问要查询的那几个字段，而是需要读取其他所有字段（可以在索引中完成整个查询的情况除外）。这样，就不得不读取包括大字段在内的很多并不相干的数据。而由于大字段所占的空间比例非常大，自然所浪费的IO资源也就相当大了。
MySQL可扩展设计需要遵循高可用及数据安全原则，经过scale out设计之后，刺痛整体性可扩展性确实会得到很大的提高，整体性能也很容易得到较大的改善。但是，系统整体的可用性和维护方面却变得比以前更加困难。因为系统整体架构复杂了，不论是应用程序还是数据库环境方面都会比原来更为庞大，更为复杂。这样，最直接的影响就是维护难度更大，系统监控更难。
如果这样的设计改造所带来的后果是系统经常性地crash，经常性地出现down机事故，大家肯定是无法接受的。因此，必须通过各种技术手段来保证系统的可用性不会降低，甚至在整体上有所提高。
这就引出了scale out设计过程中的另一个原则，也就是高可用性的原则。不论如何调整设计系统的架构，系统的整体可用性不能降低。
搭建分布式数据库集群的时候，很多人都比较关心事务的问题。因为事务是数据库中非常核心的功能。
在传统的集中式数据库架构中，事务的问题非常好解决，可以完全依赖数据库本身非常成熟的事务机制来保证。但是数据库作为分布式的架构之后，很多原来在单一数据库中所完成的事务现在需要跨多个数据库主机，这样原来的单机事务就需要引入分布式事务的概念。
分布式事务本身是一个非常复杂的机制，不管是商业的大型数据库系统，还是各开源数据库系统。虽然大多数数据库厂家基本上都实现了这个功能，但或多或少地存在限制，而且存在一些Bug，可能造成某些事务不能很好的保证，或者是不能顺利地完成。
MySQL的复制可以是基于一条语句或一条记录的，你可以在MySQL的配置参数中设定复制级别，不同复制级别的设置会影响到Master端的Binary Log记录成不同的形式。
1、Row Level
Binary Log会记录成每一行数据被修改的形式，然后在Slave端再对相同的数据进行修改。
优点：在Row Level模式下，Binary Log可以不记录执行的Query语句的上下文相关信息，只需要记录哪一条记录被修改了，修改成什么样了。所以Row Level的日志内容会非常清楚地记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。
