mysql并没有复用执行计划，也没有查看历史执行计划的功能，5.7开始有了可以通过 connect_id 查看正在执行的sql的执行计划的功能，但是如果sql执行完了，也查不到执行计划，说明mysql没有明确存储了历史的执行计划，所以也谈不上复用了。

照这个说法，每条sql通过Server层，都做一次硬解析？

不过 执行过的查询会以 key-value 的形式缓存起来（开启查询缓存功能，实际生产环境一般不开） ，在这种情况下，相同的sql执行结果集会立刻从缓存中取出返回，也算是一种执行计划的复用吧

prepare statement做绑定变量的时候，会起到什么效果

MySQL prepare语句的SQL语法
Prepare在execute阶段可以节省硬解析的时间。
如果sql只执行一次，且以prepare的方式执行，那么sql执行需两次与服务器交互（Prepare和execute）,
而以普通（非prepare）方式，只需要一次交互。
这样使用prepare带来额外的网络开销，可能得不偿失。
如果是同一sql执行多次的情况，比如以prepare方式执行10次，那么只需要一次硬解析。
这时候额外的网络开销就显得微乎其微了。因此prepare适用于频繁执行的SQL。

也可以参考官方文档
prepare
prepared statement也是伴随会话的，会话消失，prepared statement效果也没有了

The scope of a prepared statement is the session within which it is created, which as several implications:

A prepared statement created in one session is not available to other sessions.

When a session ends, whether normally or abnormally, its prepared statements no longer exist. If auto-reconnect is enabled, the client is not notified that the connection was lost. For this reason, clients may wish to disable auto-reconnect. See Section 27.7.19, “C API Automatic Reconnection Control”.

A prepared statement created within a stored program continues to exist after the program finishes executing and can be executed outside the program later.

A statement prepared in stored program context cannot refer to stored procedure or function parameters or local variables because they go out of scope when the program ends and would be unavailable were the statement to be executed later outside the program. As a workaround, refer instead to user-defined variables, which also have session scope; see Section 9.4, “User-Defined Variables”.