nicht angemeldet
MySQL GROUP_CONCAT mit UNION ALL kleineres Limit?
suit
MySQL GROUP_CONCAT mit UNION ALL kleineres Limit?
suit
Hallo,
ich hab' hier ein seltsames Problem.
Folgende Abfrage:
(
SELECT
pid,
GROUP_CONCAT(bodytext ORDER BY sorting SEPARATOR '// nächster datensatz //') as text,
'' as image
FROM
tt_content
WHERE
pid = 100
GROUP BY
pid
ORDER BY
sorting
)
Funktioniert einwandfrei, ich bekomme im "text" maximal exakt 1023 Zeichen anzeigt.
Folgende Ergänzung:
(
SELECT
pid,
GROUP_CONCAT(bodytext ORDER BY sorting SEPARATOR '// nächster datensatz //') as text,
'' as image
FROM
tt_content
WHERE
pid = 100
GROUP BY
pid
ORDER BY
sorting
) UNION ALL (
SELECT '1' as pid, '2' as text, '3' as image
)
Nun bekomme ich - aus mir unverständlichen Gründen - bei 'text' nur noch 341 Bytes daher, das ist exakt 1/3 von 1023. Reduziert ein UNION ALL das Bytelimit für GROUP_CONCAT() oder habe ich irgendwas übersehen?
Danke im voraus
-
Hallo suit,
Funktioniert einwandfrei, ich bekomme im "text" maximal exakt 1023 Zeichen anzeigt.
Folgende Ergänzung:
[...]
Nun bekomme ich - aus mir unverständlichen Gründen - bei 'text' nur noch 341 Bytes daher, das ist exakt 1/3 von 1023. Reduziert ein UNION ALL das Bytelimit für GROUP_CONCAT() oder habe ich irgendwas übersehen?
prüfe, ob Du im zweiten Fall eine UTF-8-Zeichencodierung erzeugst.
Freundliche Grüße
Vinzenz
-
Nun bekomme ich - aus mir unverständlichen Gründen - bei 'text' nur noch 341 Bytes daher, das ist exakt 1/3 von 1023. Reduziert ein UNION ALL das Bytelimit für GROUP_CONCAT() oder habe ich irgendwas übersehen?
prüfe, ob Du im zweiten Fall eine UTF-8-Zeichencodierung erzeugst.
Blöde Frage: wie mache ich das?
Wenn ich die zuerst genannte Abfrage 2x mit UNION ALL verbinde tritt übrigens dasselbe Problem auf - sprich in beiden gelieferten Datensätzen ist die Länge auf 341 beschnitten.
-
Hallo,
Wenn ich die zuerst genannte Abfrage 2x mit UNION ALL verbinde tritt übrigens dasselbe Problem auf - sprich in beiden gelieferten Datensätzen ist die Länge auf 341 beschnitten.
erzwinge die von Dir gewünschte Zeichencodierung mit CONVERT(... USING ...).
Freundliche Grüße
Vinzenz
-
Wenn ich die zuerst genannte Abfrage 2x mit UNION ALL verbinde tritt übrigens dasselbe Problem auf - sprich in beiden gelieferten Datensätzen ist die Länge auf 341 beschnitten.
erzwinge die von Dir gewünschte Zeichencodierung mit CONVERT(... USING ...).
Funktioniert danke. Ich verstehe aber nicht warum :)
Der String ist ein relativ gewöhnlicher Blindtext ohne einem nennenswerten Vorkommen irgendwelcher Zeichen die sich nicht auch innerhalb 7 Bit abbilden ließen - die drastische Reduktion auf 1/3 erschließt sich mir also nicht.
Weiters läuft "alles" in UTF-8 - die Datenbankverbindung wurde zudem mit SET NAMES 'utf8' aufgebaut.
Irgendwelche Zeichencodierungsprobleme mit exotischen Zeichen gabs ebenfalls nicht ob da nun irgendwelche chinesischen Zeichen daherkommen oder hundsgewöhnliche ist egal - das Limit scheint 1023 bzw 341 Zeichen zu sein, nicht 341 Bytes.
-
Hi!
erzwinge die von Dir gewünschte Zeichencodierung mit CONVERT(... USING ...).
Ich würde ja im MySQL-Handbuch zur Funktion GROUP_CONCAT() nachlesen und die dortige Information berücksichtigen, dann braucht es auch keine Konvertierung in 1-Byte-Kodierungen nebst potentiellem Zeichenverlust.
Funktioniert danke. Ich verstehe aber nicht warum :)
Das steht nicht dort im Handbuch, aber beim Index müsste es erwähnt sein, dass bei seinen Längenbegrenzungen in Byte gezählt wird und dass bei UTF-8 3 Byte pro Zeichen veranschlagt werden, egal ob sie nun benötigt werden oder nicht.
[...] das Limit scheint 1023 bzw 341 Zeichen zu sein, nicht 341 Bytes.
Und siehe da, 1024 / 3 ist 341 und ein Rest-Byte.
Lo!
-
Ich würde ja im MySQL-Handbuch zur Funktion GROUP_CONCAT() nachlesen und die dortige Information berücksichtigen, dann braucht es auch keine Konvertierung in 1-Byte-Kodierungen nebst potentiellem Zeichenverlust.
Da konnte ich nichts für micht Geignetes herrauslesen.
Das steht nicht dort im Handbuch, aber beim Index müsste es erwähnt sein, dass bei seinen Längenbegrenzungen in Byte gezählt wird und dass bei UTF-8 3 Byte pro Zeichen veranschlagt werden, egal ob sie nun benötigt werden oder nicht.
Und siehe da, 1024 / 3 ist 341 und ein Rest-Byte.
Das erklärt einiges - jetzt wird's klar. Danke für die Ergänzung.
-
Hallo,
Ich würde ja im MySQL-Handbuch zur Funktion GROUP_CONCAT() nachlesen und die dortige Information berücksichtigen, dann braucht es auch keine Konvertierung in 1-Byte-Kodierungen nebst potentiellem Zeichenverlust.
Da konnte ich nichts für micht Geignetes herrauslesen.
Wenn Du mehr als 1024 Bytes benötigst, kannst Du die maximale (Byte-)Länge der zurückgegebenen Zeichenkette hochseten:
SET [GLOBAL | SESSION] group_concat_max_len = val;Freundliche Grüße
Vinzenz
-
-
Moin Moin!
Das steht nicht dort im Handbuch, aber beim Index müsste es erwähnt sein, dass bei seinen Längenbegrenzungen in Byte gezählt wird und dass bei UTF-8 3 Byte pro Zeichen veranschlagt werden, egal ob sie nun benötigt werden oder nicht.
Lustiger Anstz. Vor allem, wenn man bedenkt, dass ein Zeichen in UTF-8 auch mal 4 Bytes belegen kann.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hi!
Das steht nicht dort im Handbuch, aber beim Index müsste es erwähnt sein, dass bei seinen Längenbegrenzungen in Byte gezählt wird und dass bei UTF-8 3 Byte pro Zeichen veranschlagt werden, egal ob sie nun benötigt werden oder nicht.
Lustiger Anstz. Vor allem, wenn man bedenkt, dass ein Zeichen in UTF-8 auch mal 4 Bytes belegen kann.MySQL unterstützt nur die BMP, weswegen keine 4-Byte-Zeichen vorkommen können.
Lo!
-
-
-
-
-
-