Comments on: Why MySQL Stored Procedures, Functions and Triggers Are Bad For Performance https://www.percona.com/blog/why-mysql-stored-procedures-functions-triggers-bad-performance/ Mon, 06 May 2019 15:12:00 +0000 hourly 1 https://wordpress.org/?v=6.5.2 By: rvitwadmin https://www.percona.com/blog/why-mysql-stored-procedures-functions-triggers-bad-performance/#comment-10969984 Thu, 22 Nov 2018 08:24:46 +0000 https://www.percona.com/blog/?p=51183#comment-10969984 Hello Alexander, thanks for writing this, and while it it is helpful to understand how dead code can impact performance, 95% of all stored procedures don’t contain dead code. I would be much more interested in some real world benchmarks (select, insert, delete, update, complex joins, etc…) compare in performance between stored procedures and inline sql (I come from a MSSQL Server background, where the stored procs are compiled / query plans are cached and give you a significant performance boost. I understand this may not be the case with MySQL, but I would not want to ditch the logic abstraction layer of stored procedures unless there is a significant, real world performance hit. Thanks! ( I may run a few benchmarks myself, if I do I will post here )

]]>
By: Tochi https://www.percona.com/blog/why-mysql-stored-procedures-functions-triggers-bad-performance/#comment-10969858 Wed, 24 Oct 2018 02:23:20 +0000 https://www.percona.com/blog/?p=51183#comment-10969858 Though the article is helpful, I don’t like the subject because it seems to discourage stored procedures, functions and triggers. Triggers intrinsically impact performance. I have no doubt. Stored procedures, functions are there for good reasons. The subject should be like Tips that prevent stored procedures, triggers and functions from slowing down performance.

]]>
By: Alexander Rubin https://www.percona.com/blog/why-mysql-stored-procedures-functions-triggers-bad-performance/#comment-10969553 Mon, 13 Aug 2018 17:54:18 +0000 https://www.percona.com/blog/?p=51183#comment-10969553 I was trying to find out how this works and found this comment in sql/sql_class.h
(https://github.com/mysql/mysql-server/blob/4f1d7cf5fcb11a3f84cff27e37100d7295e7d5ca/sql/sql_class.h)

/*
Enum enum_locked_tables_mode and locked_tables_mode member are
used to indicate whether the so-called “locked tables mode” is on,
and what kind of mode is active.
Locked tables mode is used when it’s necessary to open and
lock many tables at once, for usage across multiple
(sub-)statements.
This may be necessary either for queries that use stored functions
and triggers, in which case the statements inside functions and
triggers may be executed many times, or for implementation of
LOCK TABLES, in which case the opened tables are reused by all
subsequent statements until a call to UNLOCK TABLES.
The kind of locked tables mode employed for stored functions and
triggers is also called “prelocked mode”.
In this mode, first open_tables() call to open the tables used
in a statement analyses all functions used by the statement
and adds all indirectly used tables to the list of tables to
open and lock.
It also marks the parse tree of the statement as requiring
prelocking. After that, lock_tables() locks the entire list
of tables and changes THD::locked_tables_modeto LTM_PRELOCKED.
All statements executed inside functions or triggers
use the prelocked tables, instead of opening their own ones.
Prelocked mode is turned off automatically once close_thread_tables()
of the main statement is called.
*/

]]>
By: Zane https://www.percona.com/blog/why-mysql-stored-procedures-functions-triggers-bad-performance/#comment-10969431 Tue, 17 Jul 2018 12:23:49 +0000 https://www.percona.com/blog/?p=51183#comment-10969431 nice article,thank you

]]>
By: Jerry Wilborn https://www.percona.com/blog/why-mysql-stored-procedures-functions-triggers-bad-performance/#comment-10969386 Fri, 13 Jul 2018 16:38:53 +0000 https://www.percona.com/blog/?p=51183#comment-10969386 Assuming Oracle (or Percona) fixes the bug (feature?) of MySQL opening tables unnecessarily, then it sounds like there would be no performance impact in using the functions (even with never-executed branches). Right?

Second question: What tables is it even trying to open? You’re doing a select on a function… I’m confused.

]]>
By: dbdemon https://www.percona.com/blog/why-mysql-stored-procedures-functions-triggers-bad-performance/#comment-10969376 Thu, 12 Jul 2018 20:37:48 +0000 https://www.percona.com/blog/?p=51183#comment-10969376 Interesting findings! I tried declaring the functions with the DETERMINISTIC characteristic, but it made no difference.

I also tried reproducing your results with MariaDB 10.3 and got similar results for func1 vs func2, but func3 performed somewhat better, relatively speaking: func1 x 1M: 1.739 sec, func2 x 1M: 2.249 sec, func3 x 1M: 3.054 sec.

I also tried reproducing the issue with actual stored procedures. The benchmark function doesn’t support calling stored procedures, so I wrote my own benchmark stored procedure. This appears to introduce some overhead compared to the built-in benchmark function, so the results are not directly comparable, but there appears to be a similar effect with stored procedures, i.e. that func2 is slower than func1, and that func3 is slower than func2.

]]>
By: houndegnonm87 https://www.percona.com/blog/why-mysql-stored-procedures-functions-triggers-bad-performance/#comment-10969374 Thu, 12 Jul 2018 20:04:44 +0000 https://www.percona.com/blog/?p=51183#comment-10969374 Nice article, Very well explained and thanks fro drawing the full picture

]]>