tag:blogger.com,1999:blog-6428405298205573074.comments2022-03-31T14:43:41.578+05:30Learn MySQLNavjyothttp://www.blogger.com/profile/10947311044610057980noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6428405298205573074.post-80346266555225701272014-08-18T20:56:43.375+05:302014-08-18T20:56:43.375+05:30testing...testing...Navjyothttps://www.blogger.com/profile/10947311044610057980noreply@blogger.comtag:blogger.com,1999:blog-6428405298205573074.post-48555201917351620052012-11-08T10:00:26.258+05:302012-11-08T10:00:26.258+05:30A legit online jobs scam commonly would guise as p...A legit online jobs scam commonly would guise as people who have pure intentions of helping others by sharing what products and schemes they have.<br /><a href="http://elegitonlinejobs.com/legit-online-jobs-scam/" rel="nofollow">legit online jobs scam</a>Anonymoushttps://www.blogger.com/profile/06889719935909152328noreply@blogger.comtag:blogger.com,1999:blog-6428405298205573074.post-26412329385862909342011-02-10T21:43:22.768+05:302011-02-10T21:43:22.768+05:30On slide 45, four reasons are noted for partitions...On slide 45, four reasons are noted for partitions:<br /><br />1. If you have large tables<br />2. If you know that you will always query for the partitioning column<br />3. If you have historical tables that you want to purge quickly<br />4. If your indexes are larger than available RAM<br /><br />Before jumping to partitions for the above cases, which require planning, scripts, and maintenance, users should also evaluate whether they have the right storage engine support in their MySQL stack. <br /><br />For #1, there is a perception that smaller tables are faster. However, a collection of small tables that you have to swap in and out is not necessarily faster than a single table, parts of which you have to swap in and out. We (Tokutek) have written about this in http://tokutek.com/2011/01/partitioning-free-lunches-and-indexing/. We’ve also had customers go up to billions of rows http://tokutek.com/customers/a-social-networking-case-study/ and turn to TokuDB to manage performance at this level. <br /><br />For #2, Knowing you always query the partitioning column is not a reason for partitions, it is a requirement/limitation. Partitioned tables require table scans on queries that do not contain the partitioning column. This is not true for some storage engines, such as Tokutek’s TokuDB. With TokuDB and proper indexes, this requirement disappears. Queries that contain the "partitioning column" can perform well, as well as other queries.<br /><br />For #3, I can see the value, at least for an InnoDB implementation. That said, the new change buffer in InnoDB will also likely reduce the importance of this reason for partitions in InnoDB implementations. TokuDB, however, can be orders of magnitude faster than InnoDB for deletions, and this may be fast enough in many cases to eliminate need for partitions. <br /><br />For #4 (also noted in slide 74), indexes without RAM may be limiting for typical B-Tree structures found in default MySQL storage engines (MyISAM, InnoDB, etc..). <br />However this is not true for all storage engines. For Tokutek’s TokuDB, secondary indexes that don’t fit in memory are not a problem, as index creation does not exact write penalties. In fact, maintaining the indexes you really want on large tables is a good methodology once the limitations of typical B Trees are overcome. So it’s not really indexing that requires RAM, it’s B-tree indexing. This is something we’ve talked about in a number of places, including http://tokutek.com/2010/04/tokudb-indexes-are-not-in-memory-and-not-hash-tables-either/Anonymoushttps://www.blogger.com/profile/16125386233294376359noreply@blogger.comtag:blogger.com,1999:blog-6428405298205573074.post-67212340988215361742010-11-11T23:13:05.153+05:302010-11-11T23:13:05.153+05:30Thanks for posting this! It's a frequent sour...Thanks for posting this! It's a frequent source of confusion for new (and some not so new) MySQL developers.<br /><br />For what it's worth, the padding of an integer, and the ZEROFILL column modifier, are not part of standard SQL, they're a MySQL-ism.<br /><br />It's understandable why there would be confusion, because the argument in CHAR(60) does mean max length.<br /><br />Perhaps MySQL should have chosen some distinct syntax to support their special feature, like INT PAD(11) or something. But that train left the station long ago.Bill Karwinhttps://www.blogger.com/profile/13004667086865377598noreply@blogger.com