Answers:
很安全，如果您要这样。只要您像对待数据安全性一样谨慎对待安全性。
但是不要浪费时间，存储过程是存储在表中的SQL位。他们支持（不鼓励）参数化。
还要注意，通过使用MySql Event Scheduler而不是cron ，可以简化安全性并减少故障点的数量并减少网络通信。
出于充分的理由，其他数据库也具有与之等效的数据库。您并不是第一个需要此功能的人。
如果要将SQL语句保存在数据库中以供以后执行，则有比将它们放在表中更好的选择：使用为此特定目的提供的内置功能。将它们放在存储过程中。
不，我会说这不是一个好主意。
这意味着每个“真实”查询/更新都需要在数据库上命中2次-一次获取“真实”查询/更新，然后执行一次。
在小型系统中，这可能不是什么大问题，但是系统获得的用户/交易越多，扩展规模就越小。
我猜想这是由于在您的代码中寻找替代方法来嵌入SQL？
正如Mason Wheeler所建议的那样，将SQL封装在存储过程中将是比这种想法好得多的一种方法。
有充分的理由将SQL存储在表中。我正在使用的软件现在包括一个用于生成文档的系统，并且该文档需要使用数据库中的数据进行相当复杂的计算。这些文档经常更新，在所需数据和需要执行的计算方面经常有很大不同。基本上，SQL被用作执行这些计算的脚本语言，并且SQL存储在表中，这些表还存储了这些文档的其他信息。维护这些文档的人员不是程序员或DBA，但他们熟悉数据库架构，并且精通SQL。对于他们而言，以存储过程的形式维护该SQL代码将是巨大的开销。
对于您所说的-“ ...一个需要大量cron作业的项目，这些项目将定期执行SQL语句”-其他答案可能是正确的，建议您使用存储过程或等效的DBMS。重新使用。
决定将SQL存储在表中还是将SQL存储在存储过程中的明智标准是确定谁将维护该SQL。如果用户维护该SQL，即在需要时编写并更改它，那么将SQL存储在表中可能是完全可以的，而且实际上是最好的。如果开发人员将维护该SQL，则应以可以通过您的（希望自动化的）构建和部署过程更新的形式存储该SQL，例如，将其存储为对象，例如存储过程本身在数据库中。
最简单的方法是拥有一个.ini或其他配置样式文件来保留查询。通过这种方式，您可以将它们放在一个位置，无需访问数据库即可进行任何更改，而不必多次访问数据库并且在某些时候您可能希望/需要使用参数或向查询中添加条件（针对代码中的特定情况，使用更复杂的内容为它们添加代码）。
当然，您可以将它们保留在数据库级别（在表中，或者更好的是，作为存储过程），但是，如果您像我一样懒惰；-)但也要关注性能，.ini文件和PHP钟爱的parse_ini方法来读取它是必经之路（如果您要使用另一种编程语言，则需要自己寻找类似的方法）！通常，我会在应用程序的引导加载程序中读取此文件，并将其保存在静态对象中（也许在其顶部有一个缓存层），以在我们谈论大量不同的查询时真正加快速度。