如果您发出一个prepared语句，mysql会准备一些事情，比如解析和执行计划，因此当您稍后绑定实际参数时，它不需要（再次）这样做。准备通常只需要一些ms。如果这是相关的，则取决于查询的总执行时间，显然只有多次运行它才能节省时间（但如果只运行一次也不会浪费时间）。也就是说，即使只运行一次，使用准备好的语句也是一种标准的安全措施。
准备好的语句存储在服务器上，需要（一点点）内存。当您关闭它时，它将被释放，之后不会被缓存。它也特定于一个连接，因此不同的连接将为同一个查询分配自己的内存。
您可以保持几个准备好的语句处于活动状态。实际上，open prepared语句的总计数有一个上限（由max\u prepared\u stmt\u count给出），但这将取决于有多少用户在使用你的应用程序，如果这（以及他们分配的内存，这通常还是可以忽略的）与你的考虑有关。
当持有长时间准备好的语句时，有一些实际的含义，最重要的是，当你失去连接时，准备好的语句就会丢失（无论是意外还是故意关闭连接）。这可能会也可能不会使代码复杂化（例如，重新初始化连接丢失时的语句）。它还迫使您保持连接打开，尽管mysql通常不需要太多资源来保持睡眠连接打开，但您可能想要也可能不想要。另外，这将基本上阻止您使用连接池（除非它们支持连接池），因为您无法在不丢失准备好的语句的情况下将连接返回到连接池（尽管这对于c应用程序来说通常不太相关）。
这是标准c mysql api的行为（正如您的语法所建议的）。如果使用其他工具，这种行为当然会有所不同。例如，java driverdoes（可选）缓存语句 .close . 但它基本上是通过不关闭它（通过api）来实现的，并且在内部处理诸如重新初始化连接丢失之类的事情。这意味着这样一个（应用程序端）缓存可以有一些用途，虽然我不知道有没有c替代方案，但实现它肯定是可能的（也不应该太复杂）（很可能已经有人这么做了）。
最后一点，您可能正在寻找：在mysql 8之前，有一个查询缓存来缓存特定sql查询的结果。如果您使用完全相同的代码（使用完全相同的参数）运行一个查询两次，并且没有更新所涉及的表（如果启用了缓存并且结果集不是太大），mysql将从该缓存获取结果，而不需要重新执行查询。它只与准备好的语句密切相关，对应用程序透明（您不需要更改任何内容），但可能与缓存上下文相关。