我正在使用从Access数据库迁移的旧MySQL数据库。这太糟糕了，但我无法改变这一部分。我不知道问题出在哪里，但我已经做了很多调试和试验，以找出问题所在。希望你能帮助我找到问题。
由于法律隐私原因，我无法提供具体的表格或视图定义。
db有表A，B，C ......和视图M，N，O，P，Q，R，S，T。视图是相互建立的，所以T从R + S中选择...... R + S从O + P + Q中选择。
在某个时刻，即使输入正确，视图的结果也会中断并开始返回错误的结果。
在Access中，视图R有50k行。在MySQL中，视图R有50k行。 （和数据匹配）
在Access中，视图S有35k行。在MySQL中，视图S有35k行。 （和数据匹配）
在Access中，视图T（连接R + S）有24k行。
在MySQL中，视图T有51k行，但应该有24k。这就是问题所在。
作为一个实验，我创建了镜像View R和View S的真实表（即tableR与viewR具有相同的列定义），然后选择了viewR - ＆gt; tableR和viewS-＆gt; tableS。然后我针对那些 表 而不是 视图 运行了T的查询，它运行得很好。我得到了24k行。
我尝试更改R和S的创建视图定义中的ALGORITHM。之前已将其设置为ALGORITHM=UNDEFINED。我将其更改为ALGORITHM=TEMPTABLE，然后运行T的查询。查询是SLOOOOOOW（如5分钟），但最终还是给了我正确的24k行。
所以，有我的问题。当视图使用ALGORITHM=UNDEFINED时（我认为这意味着它正在使用ALGORITHM=MERGE），那么查询很快但错误。当它使用ALGORITHM=TEMPTABLE时，它的工作速度慢，但却不正确。
什么可能导致View返回不正确的结果？
视图并不复杂，它们通常只包含带有单个连接的select语句，也可能包含where子句。他们最初是这样打破的，以帮助开发人员掌握小块状的每个步骤。