我想了一下最可能造成此次锁表的原因。你是程序在线的时候执行的knex-migrate up吗？那样这次是有可能锁死。
如果你cherry-pick了 935681b14f4f41a6af27977d5cc1cae6c2f5817a
这个是为了解决之前打错字的情况，也为了这次你执行knex-migrate up能正确运行而不至于直接挂在前面的错误文件上。
当你执行knex-migrate的时候，它会读取knex_migrations表，对比没有执行过的migration文件，然后执行并把完成的migration记录文件名到这个表里面。
也就是说本次你应该是看到执行了两个migration：
20210223200240_drop_not_null_constraints.js
20210304101412_fix_view_userMetatdata.js
然后前者20210223200240_drop_not_null_constraints.js是个什么东西呢，为了DROP t_work表里面大量多余的NOT NULL constraints，这个是上游写的bug。
然而SQLite非常麻烦的地方在于它不支持绝大多数ALTER TABLE，导致无论用什么ORM或者Query Builder最后都是得自己手写大段重建整个表的语句，具体你可以看那个文件里做了什么。
这个非常繁琐的步骤也是符合SQLite文档的：https://sqlite.org/lang_altertable.html
然而如果重建过程中或者以后导致数据库锁死，那就只有重启了。
不过现在应该不需要做什么，数据库应该是正常的。
关于Kikoeru内部的数据库迁移逻辑，请看这篇文档。
如果你看到knex_migrations表里面有两个只差一个字母的文件：
20210223200240_drop_not_null_constrains.js
20210223200240_drop_not_null_constraints.js
并不会造成问题，但是不放心你可以删掉20210223200240_drop_not_null_constrains.js这个记录。具体原因不解释了，其实是你fork unstable上线的时候我还有没测试完的草稿……
VIEW本身不存储数据，它是完全等价于subquery的。 执行
EXPLAIN QUERY PLAN SELECT * FROM userMetadata
WHERE user_name = 'admin'
ORDER BY userRating DESC, "release" DESC, id DESC;和
EXPLAIN QUERY PLAN SELECT * FROM (SELECT t_work.id,
t_work.title,
json_object('id', t_work.circle_id, 'name', t_circle.name) AS circleObj,
t_work.release,
t_work.review_count,
t_work.dl_count,
t_work.nsfw,
userrate.userRating,
userrate.review_text,
userrate.progress,
userrate.updated_at,
json_object('vas', json_group_array(json_object('id', t_va.id, 'name', t_va.name))) AS vaObj,
userrate.user_name
FROM t_work
JOIN t_circle on t_circle.id = t_work.circle_id
JOIN r_va_work on r_va_work.work_id = t_work.id
join t_va on t_va.id = r_va_work.va_id
JOIN (
SELECT t_review.work_id,
t_review.rating AS userRating,
t_review.review_text,
t_review.progress,
strftime('%Y-%m-%d %H-%M-%S', t_review.updated_at, 'localtime') AS updated_at,
t_review.user_name
FROM t_review
JOIN t_work on t_work.id = t_review.work_id
) AS userrate
ON userrate.work_id = t_work.id
GROUP BY t_work.id, userrate.user_name
) AS subquery
WHERE user_name = 'admin'
ORDER BY userRating DESC, "release" DESC, id DESC;可以看到QUERY PLAN是完全一致的。
我觉得也许有 cluster 4个实例同时读写的问题在，我不知道 sqlite 有没有在文件层实现锁，而这四个实例也没法互相协调。
我会先把实例数量降低到1来试试