- 海量数据处理
大型网站每天的数据量可能上百万，甚至上千万或更多。如果存在设计不好的多对多关系，在前期可能没有任何问题，但是随着用户增长，数据量会以几何级数增加。此时，对于一个表的select和update（还不用说多表联合查询）的成本是非常高的。
-
数据并发处理
死锁在高并发情况下存在的概率非常高，这时使用缓存仍是一个大问题。因为在整个应用范围下，缓存是全局共享的。当两个或者多个请求同时对缓存有更新要求时，尽管我们有lock机制，但并不是很灵验，应用程序还是会直接死掉。
-
文件存贮问题
当文件量是海量数据的情况下，那么维护和使用时，磁盘I/O就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应得过来。如果这个时候还涉及上传，磁盘很容易就over了。
-
数据关系处理
在Web2.0时代，数据关系大多是多对多关系，涉及的大多是多表联合查询。如果避免是一个问题。
-
数据索引问题
索引和更新是一对矛盾。廉价的索引可能带来高代价的update。
-
分布式处理
为了保证各地的访问速度，如何有效实现数据同步和更新，实现各地服务器的实时通信是一个很大的问题。
-
Ajax利弊
Ajax利用简单的post和get进行数据传递，采用HTTP debuger抓取数据，但存在攻击危险。
-
数据安全性
大型网站面临的危险主要有外挂、群发等，如采用验证码，对用户体验又是一个很意外的影响。
-
数据同步和集群处理
当数据库服务器不堪重负时，就需要做基于数据库的负载和集群了。这时可能会遇到最让人困扰的问题：根据数据库的设计不同，数据基于网络传输时会发生数据延迟。这是很可怕的问题，也不可避免。由此，我们就需要通过另外的手段来保证在这延迟的几秒或者更长时间内，实现有效的交互。比如数据散列、分割、内容、异步处理等问题。
-
Open API以及数据共享
Open API已经成为不可避免的趋势，从google,facebook,myspace到海内、校内，都在考虑这个问题，它可以更有效地留住用户，并激发用户更多参与，让更多人帮助你做最有效的开发。
-
大量like,or,in以及多表查询带来的性能屏障
-
大量上传文件攻击
把Web2.0网站用户量级别定为三种，百万级别（M）、千万级别（S）以及亿万级别（Q）。如果全表查询，可以采用分区视图、分表索引处理。对于M级别来说，主要应对的是I/O问题：对数据库的file文件分磁盘存贮（不是分区，是不同的硬盘），根据负载量大小，我们可以适当控制硬盘的数量和文件分区的数量。对于S级别，需要对注册和入库的流程进行简单修改。解决方案是数据散列和分区视图。
常用的方案有三种。第一种是等容扩充法：在用户注册控制的基础上，保证每个库的用户容量不超过500万，超过之后入第二个库，以此类推。这个方案可以保证有效的扩充性，但不能保证数据被有效索引。第二种就是共区索引方案，其实和第一种方案有异曲同工之处。但是对第一种方案进行了合理的优化，按照用户名进行了分库存贮。如建立26个数据库，按照用户名的索引来控制用户数据入哪个库。假如用户名是crazycode，那该用户名的数据存放在用户表C中。方案三是一个更具模型化的方案，进行用户ID的编码。我们用一种序列化的方案将用户名以编码的形式存贮，如crazycode按照C,R,A,......存贮为数字索引，然后进行分区存贮。数字类型的数据在数据库中可以更有效地被查询、更新和共享，这就是结合方案一和方案二的方案三。对于Q级别，可以根据用户活跃度的权值结合数据量进行临时数据表的存放。如果是在非意外的数据情况下，每天登录的用户量不会上千万。利用一个简单的数据代理程序，一个临时的用户验证数据库，每天执行一次批处理，将活跃度高的用户帐户撮到临时数据库中。查询的时候先查询临时库，如果没有，再进行全库查询。一个更高级的查询方案——数据缓存服务，就是将最常用最直接的数据直接存放在缓存服务器中，而这个缓存服务器定时从主服务器获取并更新信息。更深入地，可以将缓存服务器做二次缓存，也就是一次性处理输入并存放到list数据中，作为全局变量放到内存中进行查询，同时用散列表或者数组进行数据索引，根据查询分布到各个变量中，直接从内在中读取数据。
