我用webman做的项目，如果遇到高并发，会造成数据库数据错乱吗？

其他框架怎么处理的 现在这个就是那样去处理吧

这个是数据库层面的问题,跟框架没关系

你是不是不知道数据库有一种叫锁？ 还有一种队列不知道用么？

这个问题跟webman无关

"万物皆可高并发"[滑稽]
race condition不是框架层面去解决的问题

所有用户提交问卷都是通过操作数组，然后转json存数据库？为什么不新建一个表来保存提交问卷的记录

1. 可以尝试一下调整表结构，将“大数组”拉平，原本一条记录的，插入多条数据库记录（类似于对一篇文件的多条评论）。每次插入的记录都是一条新纪录，更新也是更新这条记录。例如用户ABC,三个用户插入过，就是三条记录，D用户进来 更新了B的，依然是三条记录。
2. 做排他性处理：给这张新表增加时间戳。 例如，当用户X,Y来操作已存在的记录的时候，展示的时候，将记录的时间戳t1 在form中hidden，提交的时候执行： UPDATE TABLE SET content={new content} WHERE id=123 AND t=t1. 如果X先于Y提交，Y就提交不了，提示，在其编辑过程中，其他用户操作过了。建议重新load。。。

这两种锁，我该使用哪个锁？

Db::table('wj_options')
->where('id', $randOptinsId)
->???  //用哪个锁?
->update($updateArr);

如果update在锁的状态时,其他用户来更新,返回false吧?

建议分表处理，为什么一张问卷表里把答案也存进去？
“我想单表更快，省下链表。”---数据量大的时候，并不见得单表能更快，而且对答案的分组分页你怎么做？如果需要查询呢？
“php不是单线程吗？一次处理一个”---PHP是单线程，但可以多进程，比方传统的php-fpm，启动一个会创建几个进程监听。

所以，分表后不存在你的疑虑，建议分表处理。
另外如果担心mysql扛不住高并发的写入，可以通过INSERT DELAYED或队列等的方式，先把要写入的内容存内存，再去写入。
担心数据丢失的话就走redis队列或RabbitMQ队列，它们不会成为你的瓶颈；
前端也做做手脚，提交的时候适当增加随机延迟参数，比如随机100~800毫秒，对用户感知不高，确能有效削峰。