{"id":4171,"date":"2011-12-02T15:55:32","date_gmt":"2011-12-02T13:55:32","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=4171"},"modified":"2011-12-02T15:55:32","modified_gmt":"2011-12-02T13:55:32","slug":"more-mysql-foreach","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/more-mysql-foreach","title":{"rendered":"More MySQL foreach()"},"content":{"rendered":"

In my previous post<\/a> I’ve shown several generic use cases for foreach()<\/em><\/a>, a new scripting functionality introduced in common_schema<\/a>.<\/p>\n

In this part I present DBA’s handy syntax for schema and table operations and maintenance.<\/p>\n

Confession: while I love INFORMATION_SCHEMA<\/strong>‘s power, I just hate<\/em> writing queries against it. It’s just so much typing! Just getting the list of tables in a schema makes for this heavy duty query:<\/p>\n

\n
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='sakila' AND TABLE_TYPE='BASE TABLE';<\/pre>\n<\/blockquote>\n
When a join is involved this really becomes a nightmare. I think it’s cumbersome, and as result, many do not remember the names and meaning of columns, making for “oh, I need to read the manual all over again just to get that query right”<\/em>. Anyway, that’s my opinion.<\/p>\n
A SHOW TABLES<\/strong> statement is easier to type, but cannot be integrated into a SELECT<\/strong> query (though we have a partial solution<\/a> for that, too), and besides, when filtering out the views, the SHOW<\/strong> statement becomes almost as cumbersome as the one on INFORMATION_SCHEMA<\/strong>.<\/p>\n
Which is why foreach()<\/em> offers handy shortcuts to common iterations on schemata and tables, as follows:<\/p>\n
Use case: iterate all databases<\/h4>\n
\n
call foreach('schema'<\/span>, 'CREATE TABLE ${schema}.event(event_id INT, msg VARCHAR(128))'<\/span>);<\/pre>\n<\/blockquote>\n
In the above we execute a query on each database. Hmmm, maybe not such a good idea to perform this operation on all databases? Let’s filter them:<\/p>\n
Use case: iterate databases by name match<\/h4>\n
\n
call foreach('schema like wordpress_%'<\/span>, 'ALTER TABLE ${schema}.wp_posts MODIFY COLUMN comment_author VARCHAR(96) NOT NULL'<\/span>);<\/pre>\n<\/blockquote>\n
The above will only iterate my WordPress databases (I have several of these), performing an ALTER<\/strong> on wp_posts<\/strong> for each of those databases.<\/p>\n
I don’t have to quote the like<\/em> expression, but I can, if I wish to.<\/p>\n
I can also use a regular expression match:<\/p>\n
\n
call foreach('schema ~ \/^wordpress_[0-9]+$\/'<\/span>, 'ALTER TABLE ${schema}.wp_posts MODIFY COLUMN comment_author VARCHAR(96) NOT NULL'<\/span>);<\/pre>\n<\/blockquote>\n
Use case: iterate tables in a specific schema<\/h4>\n
Time to upgrade our sakila<\/strong> tables to InnoDB’s compressed format. We use $()<\/strong>, a synonym for foreach()<\/em>.<\/p>\n
\n
call $('table in sakila'<\/span>, 'ALTER TABLE ${schema}.${table} ENGINE=InnoDB ROW_FORMAT=COMPRESSED'<\/span>);<\/pre>\n<\/blockquote>\n
The above will iterate on tables in sakila<\/strong>. I say tables<\/em>, since it will avoid iterating views (there is still no specific syntax for views iteration). This is done on purpose, as my experience shows there is very little in common between tables and views when it comes to maintenance and operations.<\/p>\n
Use case: iterate tables by name match<\/h4>\n
Here’s a interesting scenario: you wish to work on all tables matching some name. The naive approach would be to:<\/p>\n
\n
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'wp_posts' AND TABLE_TYPE = 'BASE TABLE'<\/pre>\n<\/blockquote>\n
Wait!<\/strong><\/em> Are you aware this may bring your server down? This query will open all databases at once, opening all .frm<\/strong> files (though thankfully not data files, since we only check for name and type).<\/p>\n
Here’s a better approach:<\/p>\n
\n
call foreach('table like wp_posts'<\/span>, 'ALTER TABLE ${schema}.${table} ENGINE=InnoDB'<\/span>);<\/pre>\n<\/blockquote>\n
(There’s now FULLTEXT to InnoDB, so the above can make sense in the near future!)<\/p>\n
The good part is that foreach()<\/em> will look for matching tables one database at a time<\/em>. It will iterate the list of database, then look for matching tables per database, thereby optimizing the query on INFORMATION_SCHEMA<\/strong>.<\/p>\n
Here, too, I can use regular expressions:<\/p>\n
\n
call $('table ~ \/^wp_.*$\/'<\/span>, 'ALTER TABLE ${schema}.${table} ENGINE=InnoDB'<\/span>);<\/pre>\n<\/blockquote>\n
Conclusion<\/h4>\n
This is work in the making, but, as someone who maintains a few productions servers, I’ve already put it to work.<\/p>\n
I’m hoping the syntax is easy to comprehend. I know that since I developed it it must be far more intuitive to myself than to others. I’ve tried to keep close on common syntax and concepts from various programming languages.<\/p>\n
I would like to get as much feedback as possible. I have further ideas and thoughts on the direction common_schema<\/a> is taking, but wish take it in small steps. Your feedback is appreciated!<\/p>\n","protected":false},"excerpt":{"rendered":"
In my previous post I’ve shown several generic use cases for foreach(), a new scripting functionality introduced in common_schema. In this part I present DBA’s handy syntax for schema and table operations and maintenance. Confession: while I love INFORMATION_SCHEMA‘s power, I just hate writing queries against it. It’s just so much typing! Just getting the […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[53,5],"tags":[67,74,24,57,50,21],"class_list":["post-4171","post","type-post","status-publish","format-standard","hentry","category-development","category-mysql","tag-common_schema","tag-hack","tag-information_schema","tag-open-source","tag-scripts","tag-sql"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-15h","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/4171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=4171"}],"version-history":[{"count":33,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/4171\/revisions"}],"predecessor-version":[{"id":4525,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/4171\/revisions\/4525"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=4171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=4171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=4171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}