MySQL Community Server 5.5.43 has been released
Dear MySQL users, MySQL Server 5.5.43 is a new version of the 5.5 production release of the world's most popular open source database. MySQL 5.5.43 is recommended for use on production systems. MySQL 5.5 includes several high-impact enhancements to improve the performance and scalability of the MySQL Database, taking advantage of the latest multi-CPU and multi-core hardware and operating systems. In addition, with release 5.5, InnoDB is now the default storage engine for the MySQL Database, delivering ACID transactions, referential integrity and crash recovery by default. MySQL 5.5 also provides a number of additional enhancements including: - Significantly improved performance on Windows, with various Windows specific features and improvements - Higher availability, with new semi-synchronous replication and Replication Heartbeat - Improved usability, with Improved index and table partitioning, SIGNAL/RESIGNAL support and enhanced diagnostics, including a new Performance Schema monitoring capability. For a more complete look at what's new in MySQL 5.5, please see the following resources: MySQL 5.5 is GA, Interview with Tomas Ulin: http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html Documentation: http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html Whitepaper: What's New in MySQL 5.5: http://www.mysql.com/why-mysql/white-papers/whats-new-in-mysql-5-5/ If you are running a MySQL production level system, we would like to direct your attention to MySQL Enterprise Edition, which includes the most comprehensive set of MySQL production, backup, monitoring, modeling, development, and administration tools so businesses can achieve the highest levels of MySQL performance, security and uptime. http://mysql.com/products/enterprise/ For information on installing MySQL 5.5.43 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/5.5/en/installing.html For upgrading from previous MySQL releases, please see the important upgrade considerations at: http://dev.mysql.com/doc/refman/5.5/en/upgrading.html MySQL Database 5.5.43 is available in source and binary form for a number of platforms from our download pages at: http://dev.mysql.com/downloads/mysql/ The following section lists the changes in the MySQL source code since the previous released version of MySQL 5.5. It may also be viewed online at: http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-43.html Enjoy! Changes in MySQL 5.5.43 (2015-04-06) Functionality Added or Changed * CMake support was updated to handle CMake version 3.1. (Bug #20344207) * The server now includes its version number when it writes the initial starting message to the error log, to make it easier to tell which server instance error log output applies to. This value is the same as that available from the version system variable. (Bug #74917, Bug #20052694) Bugs Fixed * Replication: When using a slave configured to use a special character set such as UTF-16, UTF-32, or UCS-2, the receiver (I/O) thread failed to connect. The fix ensures that in such a situation, if a slave's character set is not supported then default to using the latin1 character set. (Bug #19855907) * Ordering by a GROUP_CONCAT() result could cause a server exit. (Bug #19880368, Bug #20730220) * A malformed mysql.proc table row could result in a server exit for DROP DATABASE of the database associated with the proc row. (Bug #19875331) * For a prepared statement with an ORDER BY that refers by column number to a GROUP_CONCAT() expression that has an outer reference, repeated statement execution could cause a server exit. (Bug #19814337) * Large values of the transaction_prealloc_size system variable could cause the server to allocate excessive amounts of memory. The maximum value has been adjusted down to 128K. A similar change was made for transaction_alloc_block_size. Transactions can still allocate more than 128K if necessary; this change reduces the amount that can be preallocated, as well as the maximum size of the incremental allocation blocks. (Bug #19770858, Bug #20730053) * A server exit could occur for queries that compared two rows using the = operator and the rows belonged to different character sets. (Bug #19699237, Bug #20730155) * Certain InnoDB errors caused stored function and trigger condition handlers to be ignored. (Bug #19683834, Bug #20094067) * The optimizer could raise an assertion due to incorrectly associating an incorrect field with a temporary table. (Bug #19612819, Bug #20730129) * The server could exit due to an optimizer failure to allocate enough memory for resolving outer
store search result as new table in memory
hello Masters, I am a novice, and I am wanting to know how to achieve this: 1million plus row in a table. user runs a search, gets some results. I want to store this result in memory in a way, so that user can fire more SQL searches on this result. How is this done? I want this to go atleast upto 20 levels down. in addition, lets say when I am 4th level down, can I have the previous levels intact for making fresh searches on them? I also want to store some queries, which produce level X result, in a manner that it speeds the process in future (user do not have to make multiple searches to get to the result) initial Table||---1st search run on initial table (level 1) | |-2nd search run on previously obtained result rows (level 2) any help is highly appreciated. thank you.
Re: store search result as new table in memory
W dniu 07.04.2015 o 22:12, Rajeev Prasad pisze: 1million plus row in a table. user runs a search, gets some results. MySQL comes with query-cache, once you run your SELECT statement the results are kept in memory. Try it by running big query and then rerun it, the second time it will take miliseconds to complete. I want to store this result in memory in a way, so that user can fire more SQL searches on this result. How is this done? I want this to go atleast upto 20 levels down. in addition, lets say when I am 4th level down, can I have the previous levels intact for making fresh searches on them? I also want to store some queries, which produce level X result, in a manner that it speeds the process in future (user do not have to make multiple searches to get to the result) I don't really understand the point of it, quering and later adding another WHERE statements would be OK. It all really depends on what are you writing your client in. You can check out Memory engine in MySQL; it provides a way to create a proper MySQL struct (no blobs/big text) that is stored in server's memory. And if searching is really your bread and butter you can use MySQL as a storage engine that feeds into something like Elastic Search. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: store search result as new table in memory
On 4/7/2015 4:12 PM, Rajeev Prasad wrote: hello Masters, I am a novice, and I am wanting to know how to achieve this: 1million plus row in a table. user runs a search, gets some results. I want to store this result in memory in a way, so that user can fire more SQL searches on this result. How is this done? I want this to go atleast upto 20 levels down. in addition, lets say when I am 4th level down, can I have the previous levels intact for making fresh searches on them? I also want to store some queries, which produce level X result, in a manner that it speeds the process in future (user do not have to make multiple searches to get to the result) initial Table||---1st search run on initial table (level 1) | |-2nd search run on previously obtained result rows (level 2) any help is highly appreciated. thank you. Temporary tables are going to become your very good friends. They will be how you store your results for later reuse. You can pick from any available storage engines to that instance. If your levels are going to have a lot of data in them, then you can exhaust your heap if you store them all using the MEMORY storage engine. For those, you will want to use InnoDB or MyISAM. The advantage to using temporary tables is that they can have indexes on them. You can create the indexes when you create the table or you can ALTER the table later to add them. CREATE TEMPORARY TABLE Level1(key(a)) ENGINE=INNODB SELECT a,b,c,d...FROM source_data; CREATE TEMPORARY TABLE Level2 ENGINE=MEMORY SELECT ... FROM Level1 ALTER TABLE Level2 ADD KEY(d,c); If you don't want the column names and data types determined for you by the results of the SELECT, you can create define the columns explicitly then populate the table using INSERT...SELECT... instead. CREATE TEMPORARY TABLE name_goes_here ( a int , b varchar(50 , c datetime ... ) ENGINE=... (pick which engine you want to use or let it chose the default for that database by not using any ENGINE= as part of the definition) Yours, -- Shawn Green MySQL Senior Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN You or someone you know could be a presenter at Oracle Open World! The call for proposals is open until April 29. https://www.oracle.com/openworld/call-for-proposals.html -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
