MongoDB是一种非关系型数据库，它支持分布式存储和高可用性。为了实现高可用性，MongoDB提供了复制集的功能，即将数据在多个节点之间进行同步和备份。复制集中有一个主节点（primary）和多个从节点（secondary），主节点负责处理客户端的读写请求，从节点负责从主节点复制数据，并在主节点故障时接替其角色。
复制集中的数据同步是通过oplog（操作日志）来实现的，oplog是一个特殊的集合，记录了主节点上所有的数据修改操作。从节点定期从主节点获取oplog，并应用到自己的数据上，以保持和主节点一致。oplog的大小是有限的，当oplog满了之后，会覆盖最旧的操作记录。因此，从节点必须在oplog被覆盖之前获取并应用oplog，否则就会出现数据不一致的情况。
为了保证数据的一致性，MongoDB在执行数据修改操作时，会对相关的文档或集合加锁，防止其他操作同时修改同一份数据。MongoDB支持两种锁的粒度：文档级别的锁（document-level locking）和集合级别的锁（collection-level locking）。文档级别的锁可以让多个操作同时修改不同的文档，提高并发性能；集合级别的锁则会阻塞整个集合的所有操作，降低并发性能。MongoDB根据不同的场景和版本，选择使用不同的锁粒度。
那么，MongoDB复制集会锁表吗？答案是：可能会。这取决于以下几个因素：
1.MongoDB的版本：MongoDB 3.0之前，默认使用集合级别的锁；MongoDB 3.0及以后，默认使用文档级别的锁。
2.数据库引擎：不同的数据库引擎支持不同的锁粒度。例如，MMAPv1引擎只支持集合级别的锁；WiredTiger引擎支持文档级别的锁。
3.操作类型：不同的操作类型需要不同的锁粒度。例如，插入、更新、删除操作需要文档级别的锁；创建索引、重建索引、删除集合等操作需要集合级别的锁。
4.数据量和网络延迟：如果数据量很大或者网络延迟很高，那么从节点复制oplog所需的时间就会增加，导致主节点上的oplog被覆盖的风险增加。为了避免这种情况，主节点在执行需要集合级别锁的操作时，会等待所有从节点都获取并应用了最新的oplog后才释放锁。这样就会造成主节点上该集合被长时间锁住，影响其他操作。
因此，如果我们想要避免MongoDB复制集中出现锁表问题，我们可以采取以下一些措施：
1.升级MongoDB版本到3.0及以上，并使用支持文档级别锁的数据库引擎，如WiredTiger。
2.尽量避免执行需要集合级别锁的操作，如创建索引、重建索引、删除集合等。如果必须执行这些操作，可以在业务低峰期进行，并提前通知相关的客户端。
3.优化数据结构和索引，减少数据修改操作的范围和频率。
4.增加oplog的大小，延长oplog的保留时间，减少oplog被覆盖的风险。