无论是网站建设还是任何其它系统项目中使用的数据流，锁是数据库不可分割的一部分，有了数据库锁，数据才能够在允许并发请求存在的同时，还能确保数据库ACID属性中的一致性和隔离性。但是，数据库锁有很多种，甚至连实现它们的方法也有很多种。下表中对各种开源数据库系统和第三方专有的数据库系统支持的各种锁类型进行了概述。
|
锁类型 |
说明 |
|
隐式锁 |
是数据库代表请求生成的，用于执行某些事务的锁。通常是必要时为某些DML（数据操作语言）任务完成的。 |
|
显示锁 |
用户在与数据库中的实体交互时定义的锁，有用户自定义。 |
|
行锁 |
可以锁住数据库表中正在被更新，被读或被创建中的一行，防止当前行数据被多个并发请求更改引起数据的不稳定状态。 |
|
页锁 |
可以锁住具有正在被更新的行或行组的分页，只有在数据表分页的表中才存在。 |
|
范围锁 |
通常，这种锁锁住的一组是分页。在添加数据库空间时，这种锁很常见。 |
|
表锁 |
锁住整个表，也就是锁住数据库中的一个实体。 |
|
数据库锁 |
锁住整个数据库中所有的表和关系，这也是数据库中最大范围和最危险的锁，慎用！ |
搜索一下，你就会发现各种类型的锁。根据数据库的类型，主关键字和索引锁可以锁住在表上创建的索引。通常网站建设人员还会发现关于锁的讨论，以及不同数据库支持各种锁的方法。据我们对部分深圳网站建设公司的调查和了解，很少公司真的会用到这么多类型的锁，即使数据库支持它们，在行业内也很少会用到。
虽然锁对数据库实现一致性和隔离性至关重要，但显然一些锁的使用成本很高。这个使用成本是由锁的范围决定的，比如表锁，会将整个数据表锁住，在表被锁住的时间里其他任何对这个表的请求都将被拒绝，这意味着其它用户必须等待，直到这个表的锁被释放出来。因此，锁的使用成本就是整个网站对数据库中被锁数据的使用等待时间，这个等待时间直接影响到了网站用户的使用时间，流畅度和用户体验，因此数据库锁的使用是要以网站建设的用户体验作为代价的。
通常，数据库是允许并发式的数据读取的，但在写数据的过程中会阻止所有的读操作。读操作一般会发生得很快，也在瞬间完成，所以许多读操作可以同时发生，但写操作就通常是在隔离的状态下进行的。写操作的颗粒度越精细，例如只写一行，那么在数据库中甚至在表中能同时发生的写操作就多。提高被写或更新的对象颗粒度，如同时更新多个行，就可能需要提高必要的锁类型，也就是提高锁的作用范围。
在网站建设项目中，采用的数据库锁的大小或粒度最终会影响事务的吞吐量。如果同时更新数据库中的多个行，那么获得多个锁的成本和对这些行的竞争会造成每秒处理的事务量比只获得更大粒度的锁要少。但如果采用的锁范围太大，例如在只需要更新很少几行数据的情况下采用了页锁，那么在锁定的期间，事务的吞吐量也会降低的。
通常，网站建设数据库的一个组件决定了采用的粒度，在允许最大并发性的同时，还能确保一致性和隔离性。在大多的情况下，最初采用这个组件决定什么需要被锁住是最好的方案。数据库的这个组件在运行时比网站建设人员更清楚哪些是可能被更新的。遗憾的是，这些系统一定会出错，这就是为什么一定要监控生成环境中的数据库，当从生成环境中了解到发生了什么时，要修改我们的DML使得它们更加有效。
网站建设中使用的大多数数据库都具有收集性能统计信息的功能，从中我们可以了解到最常见的锁定条件以及造成事务在处理前等待的最常见事件。通过分析历史信息，并且积极地监控生成环境中的事件，我们就能发现某种类型的锁使用得不对，强制性地使数据库采用正确类型的锁。例如，如果通过分析，我们发现数据库总是对某个特定的表使用锁，而我们认为采用行锁会得到更大的并发性，那么就必须强行更改。
与分析瓶颈同样重要，网站建设人员应该分析是否可以通过修改实体和外键关系来减少争用，提高并发性。数据库的横向扩展是解决这类问题的较好方法，也就是将读操作分布到数据库的多个只读副本上，而只在一个主数据库上进行写操作。当然也可以根据部分的争用问题，将表分布到多个数据库中，这属于数据库的纵向扩展。最后，我们也可以把客户的详细数据分放在多个表中，从而减少表的大小，把争用分布到多个实体上。
最后，在采用数据库的网站建设项目中，应该确保选中了最佳的解决方案。我们一再对深圳网站建设公司强调，你能用任何技术对几乎任何产品进行扩展。也就是说，我们做的大多数决定会对网站建设项目或产品的上市时间造成影响。例如，有的数据库存储引擎解决方案限制了数据库中可以采用的锁类型，从而就限制了数据库的调优能力，不能最大化并发的事务数了。MySql就是一个例子，如果选择了MyISAM作为存储引擎，就会限制表级的锁，从而可能会限制事务的吞吐量。