Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 6 reacties, 3.238 views •
Bron: Oracle, submitter: djjef85

MySQL is een krachtige opensourcedatabaseserver die met name populair is als website- en forumdatabase. Ook Tweakers.net maakt gebruik van MySQL om onder andere gebruikersgegevens, statistieken en diverse review-, meuk- en nieuwsartikelen op te slaan. De ontwikkelaars hebben een nieuwe versie van de 5.1-tak uitgebracht. Het gaat om versie 5.1.44 en voor meer informatie over de verbeteringen in de 5.1-tak verwijzen we jullie door naar deze pagina. De lijst met veranderingen ten opzichte van versie 5.1.43 ziet er als volgt uit:

Changes in MySQL 5.1.44

InnoDB Plugin Notes:
  • This release includes InnoDB Plugin 1.0.6. This version is considered of Release Candidate (RC) quality. In this release, the InnoDB Plugin is included in source and binary distributions, except RHEL3, RHEL4, SuSE 9 (x86, x86_64, ia64), and generic Linux RPM packages. It also does not work for FreeBSD 6 and HP-UX or for Linux on generic ia64.
Functionality added or changed:
  • Replication: Introduced the --binlog-direct-non-transactional-updates server option. This option causes updates using the statement-based logging format to tables using non-transactional engines to be written directly to the binary log, rather than to the transaction cache.
    Before using this option, be certain that you have no dependencies between transactional and non-transactional tables. A statement that both selects from an InnoDB table and inserts into a MyISAM table is an example of such a dependency. For more information, see Section 16.1.3.4, “Binary Log Options and Variables”. (Bug#46364)
    See also Bug#28976, Bug#40116.
Bugs fixed:
  • Performance: The method for comparing INFORMATION_SCHEMA names and database names was nonoptimal and an improvement was made: When the database name length is already known, a length check is made first and content comparison skipped if the lengths are unequal. (Bug#49501)
  • Performance: The MD5() and SHA1() functions had excessive overhead for short strings. (Bug#49491)
  • Partitioning: When an ALTER TABLE ... REORGANIZE PARTITION statement on an InnoDB table failed due to innodb_lock_wait_timeout expiring while waiting for a lock, InnoDB did not clean up any temporary files or tables which it had created. Attempting to reissue the ALTER TABLE statement following the timeout could lead to storage engine errors, or possibly a crash of the server. (Bug#47343)
  • Replication: In some cases, inserting into a table with many columns could cause the binary log to become corrupted. (Bug#50018) See also Bug#42749.
  • Replication: When using row-based replication, setting a BIT or CHAR column of a MyISAM table to NULL, then trying to delete from the table, caused the slave to fail with the error Can't find record in table. (Bug#49481, Bug#49482)
  • Replication: When logging in row-based mode, DDL statements are actually logged as statements; however, statements that affected temporary tables and followed DDL statements failed to reset the binary log format to ROW, with the result that these statements were logged using the statement-based format. Now the state of binlog_format is restored after a DDL statement has been written to the binary log. (Bug#49132)
  • Replication: When using row-based logging, the statement CREATE TABLE t IF NOT EXIST ... SELECT was logged as CREATE TEMPORARY TABLE t IF NOT EXIST ... SELECT when t already existed as a temporary table. This was caused by the fact that the temporary table was opened and the results of the SELECT were inserted into it when a temporary table existed and had the same name. Now, when this statement is executed, t is created as a base table, the results of the SELECT are inserted into it — even if there already exists a temporary table having the same name — and the statement is logged correctly. (Bug#47418) See also Bug#47442.
  • Replication: Due to a change in the size of event representations in the binary log, when replicating from a MySQL 4.1 master to a slave running MySQL 5.0.60 or later, the START SLAVE UNTIL statement did not function correctly, stopping at the wrong position in the log. Now the slave detects that the master is using the older version of the binary log format, and corrects for the difference in event size, so that the slave stops in the correct position. (Bug#47142)
  • The SSL certificates in the test suite were about to expire. They have been updated with expiration dates in the year 2015. (Bug#50642)
  • The printstack function does not exist on Solaris 8 or earlier, which would lead to a compilation failure. (Bug#50409)
  • A user could see tables in INFORMATION_SCHEMA.TABLES without appropriate privileges for them. (Bug#50276)
  • Debug output for join structures was garbled. (Bug#50271)
  • The filesort sorting method applied to a CHAR(0) column could lead to a server crash. (Bug#49897)
  • sql_buffer_result had an effect on non-SELECT statements, contrary to the documentation. (Bug#49552)
  • In some cases a subquery need not be evaluated because it returns only aggregate values that can be calculated from table metadata. This sometimes was not handled by the enclosing subquery, resulting in a server crash. (Bug#49512)
  • Mixing full-text searches and row expressions caused a crash. (Bug#49445)
  • Creating or dropping a table with 1023 transactions active caused an assertion failure. (Bug#49238)
  • mysql-test-run.pl now recognizes the MTR_TESTCASE_TIMEOUT, MTR_SUITE_TIMEOUT, MTR_SHUTDOWN_TIMEOUT, and MTR_START_TIMEOUT environment variables. If they are set, their values are used to set the --testcase-timeout, --suite-timeout, --shutdown-timeout, and --start-timeout options, respectively. (Bug#49210)
Versienummer:5.1.44
Releasestatus:Final
Besturingssystemen:OS X, BSD, Linux, UNIX, Solaris, Windows Server 2008, Windows Vista x64, Windows Vista, Windows Server 2003 x64, Windows XP x64, Windows Server 2003, Windows XP, Windows 2000, Windows 7 x64, Windows 7
Website:Oracle
Download:http://www.mysql.com/downloads/mysql/5.1.html
Licentietype:Voorwaarden (GNU/BSD/etc.)

Reacties (6)

Het blijft jammer dat het nog steeds niet mogelijk is om de opmaak van een view op te slaan. Als je nu een ingewikkelde view hebt dan kun je het alleen opvragen als 1 lange regel met text, haakjes en quotes.
Op dit na, is het een prima product!
vreemd, stored procedures worden wel met layout intact opgeslagen en geretourneerd!
Dat is zo'n beetje bij elk database systeem dat views ondersteund :)
Ze worden veelal anders opgeslagen dan jij ze hebt aangemaakt, bij PostgreSQL worden enkele syntax optimalisaties doorgevoerd.

Daarom doe ik altijd een none-compiled versie opslaan ter referentie en back-up.
Op dit na, is het een prima product!
Welke van de volgende "features" zijn dan inmiddels verbeterd?

yapf.net

Mocht je punten hebben gevonden, kunnen deze van de lijst worden geschrapt.

Zeker zolang MySQL stug blijft vasthouden aan de SQL-mode die iedereen kan aanpassen en die standaard fout staat ingesteld, zal MySQL geen betrouwbaar product worden.
Het ligt er maar aan waar je MySQL voor gebruikt. Als je MySQL enkel gebruikt als een grote doos om data in op te slaan, en alle vallidatie in je applicatie houdt, en je gebruikt als storage engine InnoDB, dan is er niks aan de hand.

Daarbij geven het grootste deel van de validatie fouten die in het document worden genoemd warnings. Dus als je in je applicatie netjes de warnings uitleest, en de transactie terugrold als er wat aan het handje is, dan voorkomt dat al een groot deel van de problemen.

Bovendien is een groot gedeelte van wat in het document staat niet waar:

Strings zijn niet hoofdlettergevoelig
Is afhankelijk van je charset.

JOINS in UPDATE en DELETE
ON UPDATE CASCADE en ON DELETE CASCADE worden wel ondersteund in innodb.

References in CREATE TABLE worden genegeerd
Innodb gebruiken

FLOAT is bij benadering correct
FLOAT is per definitie een benadering van een decimale waarde. Daarbij kan het converteren van een float naar een double geen gegevensverlies opleveren, omdat een double een hogere precisie biedt.

Geen IP-address type
Er staat "je kunt er niets meer mee dan hoger/lager controleren. " en vervolgens "In een echt INET type kun je ook subnet maskers toepassen en controleren of een adres in een bereik ligt. ". Zowel een subnet masker als een bereik zijn in princiepe een 2 hoger/lager checks.

Geen goede hot backup (alle versies)
Er zijn verschillende hot backup oplossingen voor InnoDB waaronder de open source xtrabackup. Hot backup heeft in MyISAM verrassend weinig zin omdat er wegens het gebrek aan transacties toch niet zoiets bestaat als een gegarandeerde consistente staat.

Geen point-in-time recovery in MyISAM, alleen in InnoDB (alle versies)
Gebruik binary logging, en voer alle queries sinds je laatste backup opnieuw uit, met uitzondering van de delete query natuurlijk :P

Geen goede crash-recovery (alle versies)
Gebruik InnoDB

[Reactie gewijzigd door Tubbie op 2 maart 2010 02:03]

Het ligt er maar aan waar je MySQL voor gebruikt. Als je MySQL enkel gebruikt als een grote doos om data in op te slaan, en alle vallidatie in je applicatie houdt, en je gebruikt als storage engine InnoDB, dan is er niks aan de hand.
Inderdaad, MySQL is niet meer dan een kladblok :)
Daarbij geven het grootste deel van de validatie fouten die in het document worden genoemd warnings. Dus als je in je applicatie netjes de warnings uitleest, en de transactie terugrold als er wat aan het handje is, dan voorkomt dat al een groot deel van de problemen.
Geen mens/applicatie die deze warnings uitleest, maar ze zitten wel allemaal met de gebakken peren, corrupte data. En transacties, 9 van de 10 programmeurs hebben geen idee hoe transacties werken en waar ze goed voor zijn. Dat is natuurlijk niet de fout van een database, maar het heeft zeker in dit geval wel gevolgen voor de data, die is corrupt.
Bovendien is een groot gedeelte van wat in het document staat niet waar:
Bij een "groot gedeelte" verwacht ik minstens de helft van de punten, je noemt van de bijna honderd punten slechts een handjevol. Daarnaast zijn een deel van jouw punten al genoemd als mogelijke oplossingen, jouw punten vallen dus af...

MySQL is een aardig kladblokje met SQL interface, maar daarvoor kun je net zo goed SQLite nemen. Al schaalt MySQL dan wel weer ietsjes beter dan SQLite.

Op dit item kan niet meer gereageerd worden.



Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBLG

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True